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: [email protected]?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
