Open Stack

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.

   --Adam (rm_work)

On Wed, Jun 20, 2018, 11:37 Jeremy Stanley <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://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/20180620/8d4ee255/attachment.html>