Open Stack

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 <zbitter at redhat.com> 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=<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?
>
>
> 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-request at 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
>
>
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180628/20c8a336/attachment.html>