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