Re: [openstack-dev] [barbican][heat] Identifying secrets in Barbican

[Ade Lee]

On Thu, 2018-06-28 at 17:32 -0400, Zane Bitter wrote:
> On 28/06/18 15:00, Douglas Mendizabal wrote:
> > Replying inline.
> 
> [snip]
> > IIRC, using URIs instead of UUIDs was a federation pre-optimization
> > done many years ago when Barbican was brand new and we knew we
> > wanted
> > federation but had no idea how it would work.  The rationale was
> > that
> > the URI would contain both the ID of the secret as well as the
> > location
> > of where it was stored.
> > 
> > In retrospect, that was a terrible idea, and using UUIDs for
> > consistency with the rest of OpenStack would have been a better
> > choice.
> >   I've added a story to the python-barbicanclient storyboard to
> > enable
> > usage of UUIDs instead of URLs:
> > 
> > https://storyboard.openstack.org/#!/story/2002754
> 
> Cool, thanks for clearing that up. If UUID is going to become the/a 
> standard way to reference stuff in the future then we'll just use
> the 
> UUID for the property value.
> 
> > I'm sure you've noticed, but the URI that identifies the secret
> > includes the UUID that Barbican uses to identify the secret
> > internally:
> > 
> > http://{barbican-host}:9311/v1/secrets/{UUID}
> > 
> > So you don't actually need to store the URI, since it can be
> > reconstructed by just saving the UUID and then using whatever URL
> > Barbican has in the service catalog.
> > 
> > > 
> > > In a tangentially related question, since secrets are immutable
> > > once
> > > they've been uploaded, what's the best way to handle a case where
> > > you
> > > need to rotate a secret without causing a temporary condition
> > > where
> > > there is no version of the secret available? (The fact that
> > > there's
> > > no
> > > way to do this for Nova keypairs is a perpetual problem for
> > > people,
> > > and
> > > I'd anticipate similar use cases for Barbican.) I'm going to
> > > guess
> > > it's:
> > > 
> > > * Create a new secret with the same name
> > > * GET /v1/secrets/?name==created:desc=1 to find
> > > out
> > > the
> > > URL for the newest secret with that name
> > > * Use that URL when accessing the secret
> > > * Once the new secret is created, delete the old one
> > > 
> > > Should this, or whatever the actual recommended way of doing it
> > > is,
> > > be
> > > baked in to the client somehow so that not every user needs to
> > > reimplement it?
> > > 
> > 
> > When you store a secret (e.g. using POST /v1/secrets), the response
> > includes the URI both in the JSON body and in the Location: header.
> >   
> > There is no need for you to mess around with searching by name,
> > since
> > Barbican does not use the name to identify a secret.  You should
> > just
> > save the URI (or UUID) from the response, and then update the
> > resource
> > using the old secret to point to the new secret instead.
> 
> Sometimes user will want to be able to rotate secrets without
> updating 
> all of the places that they're referenced from though.
> 

The way you've described seems like the easiest way to do this, and I
agree that this seems like a reasonable and common use case for the
client.  I've added https://storyboard.openstack.org/#!/story/2002786 .

> cheers,
> Zane.
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican][heat] Identifying secrets in Barbican

[Zane Bitter]

On 28/06/18 15:00, Douglas Mendizabal wrote:

Replying inline.

[snip]

IIRC, using URIs instead of UUIDs was a federation pre-optimization
done many years ago when Barbican was brand new and we knew we wanted
federation but had no idea how it would work.  The rationale was that
the URI would contain both the ID of the secret as well as the location
of where it was stored.

In retrospect, that was a terrible idea, and using UUIDs for
consistency with the rest of OpenStack would have been a better choice.
  I've added a story to the python-barbicanclient storyboard to enable
usage of UUIDs instead of URLs:

https://storyboard.openstack.org/#!/story/2002754


Cool, thanks for clearing that up. If UUID is going to become the/a 
standard way to reference stuff in the future then we'll just use the 
UUID for the property value.



I'm sure you've noticed, but the URI that identifies the secret
includes the UUID that Barbican uses to identify the secret internally:

http://{barbican-host}:9311/v1/secrets/{UUID}

So you don't actually need to store the URI, since it can be
reconstructed by just saving the UUID and then using whatever URL
Barbican has in the service catalog.



In a tangentially related question, since secrets are immutable once
they've been uploaded, what's the best way to handle a case where
you
need to rotate a secret without causing a temporary condition where
there is no version of the secret available? (The fact that there's
no
way to do this for Nova keypairs is a perpetual problem for people,
and
I'd anticipate similar use cases for Barbican.) I'm going to guess
it's:

* Create a new secret with the same name
* GET /v1/secrets/?name==created:desc=1 to find out
the
URL for the newest secret with that name
* Use that URL when accessing the secret
* Once the new secret is created, delete the old one

Should this, or whatever the actual recommended way of doing it is,
be
baked in to the client somehow so that not every user needs to
reimplement it?



When you store a secret (e.g. using POST /v1/secrets), the response
includes the URI both in the JSON body and in the Location: header.
  
There is no need for you to mess around with searching by name, since

Barbican does not use the name to identify a secret.  You should just
save the URI (or UUID) from the response, and then update the resource
using the old secret to point to the new secret instead.


Sometimes user will want to be able to rotate secrets without updating 
all of the places that they're referenced from though.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican][heat] Identifying secrets in Barbican

[Douglas Mendizabal]

Replying inline.

On Wed, 2018-06-27 at 16:39 -0400, Zane Bitter wrote:
> We're looking at using Barbican to implement a feature in Heat[1]
> and 
> ran into some questions about how secrets are identified in the
> client.
> 
> With most openstack clients, resources are identified by a UUID. You 
> pass the UUID on the command line (or via the Python API or
> whatever) 
> and the client combines that with the endpoint of the service
> obtained 
> from the service catalog and a path to the resource type to generate
> the 
> URL used to access the resource.
> 
> While there appears to be no technical reason that barbicanclient 
> couldn't also do this, instead of just the UUID it uses the full URL
> as 
> the identifier for the resource. This is extremely cumbersome for
> the 
> user, and invites confused-deputy attacks where if the attacker can 
> control the URL, they can get barbicanclient to send a token to an 
> arbitrary URL. What is the rationale for doing it this way?
> 

IIRC, using URIs instead of UUIDs was a federation pre-optimization
done many years ago when Barbican was brand new and we knew we wanted
federation but had no idea how it would work.  The rationale was that
the URI would contain both the ID of the secret as well as the location
of where it was stored.

In retrospect, that was a terrible idea, and using UUIDs for
consistency with the rest of OpenStack would have been a better choice.
 I've added a story to the python-barbicanclient storyboard to enable
usage of UUIDs instead of URLs:

https://storyboard.openstack.org/#!/story/2002754

I'm sure you've noticed, but the URI that identifies the secret
includes the UUID that Barbican uses to identify the secret internally:

http://{barbican-host}:9311/v1/secrets/{UUID}

So you don't actually need to store the URI, since it can be
reconstructed by just saving the UUID and then using whatever URL
Barbican has in the service catalog.

> 
> In a tangentially related question, since secrets are immutable once 
> they've been uploaded, what's the best way to handle a case where
> you 
> need to rotate a secret without causing a temporary condition where 
> there is no version of the secret available? (The fact that there's
> no 
> way to do this for Nova keypairs is a perpetual problem for people,
> and 
> I'd anticipate similar use cases for Barbican.) I'm going to guess
> it's:
> 
> * Create a new secret with the same name
> * GET /v1/secrets/?name==created:desc=1 to find out
> the 
> URL for the newest secret with that name
> * Use that URL when accessing the secret
> * Once the new secret is created, delete the old one
> 
> Should this, or whatever the actual recommended way of doing it is,
> be 
> baked in to the client somehow so that not every user needs to 
> reimplement it?
> 

When you store a secret (e.g. using POST /v1/secrets), the response
includes the URI both in the JSON body and in the Location: header. 
 
There is no need for you to mess around with searching by name, since
Barbican does not use the name to identify a secret.  You should just
save the URI (or UUID) from the response, and then update the resource
using the old secret to point to the new secret instead.

> 
> Bottom line: how should Heat expect/require a user to refer to a 
> Barbican secret in a property of a Heat resource, given that:
> - We don't want Heat to become the deputy in "confused deputy
> attack".
> - We shouldn't do things radically differently to the way Barbican
> does 
> them, because users will need to interact with Barbican first to
> store 
> the secret.
> - Many services will likely end up implementing integration with 
> Barbican and we'd like them all to have similar user interfaces.
> - Users will need to rotate credentials without downtime.
> 
> cheers,
> Zane.
> 
> BTW the user documentation for Barbican is really hard to find.
> Y'all 
> might want to look in to cross-linking all of the docs you have 
> together. e.g. there is no link from the Barbican docs to the 
> python-barbicanclient docs or vice-versa.
> 
> [1] https://storyboard.openstack.org/#!/story/2002126
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican][heat] Identifying secrets in Barbican

[Rico Lin]

For now we found two ways to get a secret, with secret href or with secret
URI(which is `secrets/UUID`).
We will turn to use  secret URI for now for Heat multi cloud support, but is
there any reason for Barbican client not to
accept only secrets UUID (Secret incorrectly specified error will shows up
when only provide UUID)?



On Thu, Jun 28, 2018 at 4:40 AM Zane Bitter  wrote:

> We're looking at using Barbican to implement a feature in Heat[1] and
> ran into some questions about how secrets are identified in the client.
>
> With most openstack clients, resources are identified by a UUID. You
> pass the UUID on the command line (or via the Python API or whatever)
> and the client combines that with the endpoint of the service obtained
> from the service catalog and a path to the resource type to generate the
> URL used to access the resource.
>
> While there appears to be no technical reason that barbicanclient
> couldn't also do this, instead of just the UUID it uses the full URL as
> the identifier for the resource. This is extremely cumbersome for the
> user, and invites confused-deputy attacks where if the attacker can
> control the URL, they can get barbicanclient to send a token to an
> arbitrary URL. What is the rationale for doing it this way?
>
>
> In a tangentially related question, since secrets are immutable once
> they've been uploaded, what's the best way to handle a case where you
> need to rotate a secret without causing a temporary condition where
> there is no version of the secret available? (The fact that there's no
> way to do this for Nova keypairs is a perpetual problem for people, and
> I'd anticipate similar use cases for Barbican.) I'm going to guess it's:
>
> * Create a new secret with the same name
> * GET /v1/secrets/?name==created:desc=1 to find out the
> URL for the newest secret with that name
> * Use that URL when accessing the secret
> * Once the new secret is created, delete the old one
>
> Should this, or whatever the actual recommended way of doing it is, be
> baked in to the client somehow so that not every user needs to
> reimplement it?
>
>
> Bottom line: how should Heat expect/require a user to refer to a
> Barbican secret in a property of a Heat resource, given that:
> - We don't want Heat to become the deputy in "confused deputy attack".
> - We shouldn't do things radically differently to the way Barbican does
> them, because users will need to interact with Barbican first to store
> the secret.
> - Many services will likely end up implementing integration with
> Barbican and we'd like them all to have similar user interfaces.
> - Users will need to rotate credentials without downtime.
>
> cheers,
> Zane.
>
> BTW the user documentation for Barbican is really hard to find. Y'all
> might want to look in to cross-linking all of the docs you have
> together. e.g. there is no link from the Barbican docs to the
> python-barbicanclient docs or vice-versa.
>
> [1] https://storyboard.openstack.org/#!/story/2002126
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican][heat] Identifying secrets in Barbican

[Zane Bitter]

We're looking at using Barbican to implement a feature in Heat[1] and 
ran into some questions about how secrets are identified in the client.


With most openstack clients, resources are identified by a UUID. You 
pass the UUID on the command line (or via the Python API or whatever) 
and the client combines that with the endpoint of the service obtained 
from the service catalog and a path to the resource type to generate the 
URL used to access the resource.


While there appears to be no technical reason that barbicanclient 
couldn't also do this, instead of just the UUID it uses the full URL as 
the identifier for the resource. This is extremely cumbersome for the 
user, and invites confused-deputy attacks where if the attacker can 
control the URL, they can get barbicanclient to send a token to an 
arbitrary URL. What is the rationale for doing it this way?



In a tangentially related question, since secrets are immutable once 
they've been uploaded, what's the best way to handle a case where you 
need to rotate a secret without causing a temporary condition where 
there is no version of the secret available? (The fact that there's no 
way to do this for Nova keypairs is a perpetual problem for people, and 
I'd anticipate similar use cases for Barbican.) I'm going to guess it's:


* Create a new secret with the same name
* GET /v1/secrets/?name==created:desc=1 to find out the 
URL for the newest secret with that name

* Use that URL when accessing the secret
* Once the new secret is created, delete the old one

Should this, or whatever the actual recommended way of doing it is, be 
baked in to the client somehow so that not every user needs to 
reimplement it?



Bottom line: how should Heat expect/require a user to refer to a 
Barbican secret in a property of a Heat resource, given that:

- We don't want Heat to become the deputy in "confused deputy attack".
- We shouldn't do things radically differently to the way Barbican does 
them, because users will need to interact with Barbican first to store 
the secret.
- Many services will likely end up implementing integration with 
Barbican and we'd like them all to have similar user interfaces.

- Users will need to rotate credentials without downtime.

cheers,
Zane.

BTW the user documentation for Barbican is really hard to find. Y'all 
might want to look in to cross-linking all of the docs you have 
together. e.g. there is no link from the Barbican docs to the 
python-barbicanclient docs or vice-versa.


[1] https://storyboard.openstack.org/#!/story/2002126

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev