[openstack-dev] [tripleo] [barbican] [tc] key store in base services

Zane Bitter zbitter at redhat.com
Thu Jun 21 20:21:17 UTC 2018


On 20/06/18 17:59, Adam Harwell wrote:
> Looks like I missed this so I'm late to the party, but:
> 
> Ade is technically correct, Octavia doesn't explicitly depend on 
> Barbican, as we do support castellan generically.
> 
> *HOWEVER*: we don't just store and retrieve our own secrets -- we rely 
> on loading up user created secrets. This means that for Octavia to work, 
> even if we use castellan, we still need some way for users to interact 
> with the secret store via an API, and what that means in openstack in 
> still Barbican. So I would still say that Barbican is a dependency for 
> us logistically, if not technically.

Right, yeah, I'd call that a dependency on Barbican.

There are reportedly, however, other use cases where the keys are 
generated internally that don't depend on Barbican but can benefit from 
Castellan.

It might be a worthwhile exercise to make a list of all of the proposed 
features that have been blocked on this and whether they require user 
interaction with the key store.

> For example, internally at GoDaddy we were investigating deploying Vault 
> with a custom user-facing API/UI for allowing users to store secrets 
> that could be consumed by Octavia with castellan (don't get me started 
> on how dumb that is, but it's what we were investigating).
> The correct way to do this in an openstack environment is the openstack 
> secret store API, which is Barbican.

This is the correct answer, and thank you for being awesome :)

> So, while I am personally dealing 
> with an example of very painfully avoiding Barbican (which may have been 
> a non-issue if Barbican were a base service), I have a tough time 
> reconciling not including Barbican itself as a requirement.

On the bright side, getting everyone to deploy either Barbican or Vault 
makes it easier even for the folks who chose Vault to deploy Barbican later.

I don't think we've given up on making Barbican a base service, just 
recognised that it's a longer-term effort whereas this is something we 
can do to start down the path right now.

cheers,
Zane.

>     --Adam (rm_work)
> 
> On Wed, Jun 20, 2018, 11:37 Jeremy Stanley <fungi at yuggoth.org 
> <mailto:fungi at yuggoth.org>> wrote:
> 
>     On 2018-06-06 01:29:49 +0000 (+0000), Jeremy Stanley wrote:
>     [...]
>      > Seeing no further objections, I give you
>      > https://review.openstack.org/572656 for the next step.
> 
>     That change merged just a few minutes ago, and
>     https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services
>     now includes:
> 
>          A Castellan-compatible key store
> 
>          OpenStack components may keep secrets in a key store, using
>          Oslo’s Castellan library as an indirection layer. While
>          OpenStack provides a Castellan-compatible key store service,
>          Barbican, other key store backends are also available for
>          Castellan. Note that in the context of the base services set
>          Castellan is intended only to provide an interface for services
>          to interact with a key store, and it should not be treated as a
>          means to proxy API calls from users to that key store. In order
>          to reduce unnecessary exposure risks, any user interaction with
>          secret material should be left to a dedicated API instead
>          (preferably as provided by Barbican).
> 
>     Thanks to everyone who helped brainstorming/polishing, and here's
>     looking forward to a ubiquity of default security features and
>     functionality in future OpenStack releases!
>     -- 
>     Jeremy Stanley
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __________________________________________________________________________
> 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
> 




More information about the OpenStack-dev mailing list