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

Ade Lee alee at redhat.com
Mon Jul 2 12:39:07 UTC 2018


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=<name>&sort=created:desc&limit=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-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list