Open Stack

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.

cheers,
Zane.