On 2018-06-20 16:59:30 -0500 (-0500), 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.
> 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. 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.

The past pushback we received from operators and deployers was that
they didn't want to be required to care and feed for yet one more
API service. As a compromise, it was suggested that we at least
provide a guaranteed means for services to handle their own secrets
in a centralized and standardized manner. In practice, the wording
we arrived at is intended to drive projects to strongly recommend
deploying Barbican in cases where operators want to take advantage
of any features of other services which require user interaction
with the key store.

Making a user-facing API service a "required project" from that
perspective is a bigger discussion, in my opinion. I'm in favor of
trying, but to me this piece is the first step in such a direction.
Jeremy Stanley

Attachment: signature.asc
Description: PGP signature

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to