Open Stack

Hello Zane--
   Yes, this vision is consistent with the Barbican team's vision.

   Barbican provides an abstraction layer over HSMs and other secret
storage services.  We have a plugin architecture to enable this
abstraction over a variety of backends.  Vault is a recent addition to our
supported options.  Barbican uses Keystone for authentication and
oslo.policy for RBAC, which allows for multi-tenancy and makes secret
storage consistent with other OpenStack services.

   The topic of cross-project dependencies is one we've been wrestling
with for a while.  At the Pike PTG[1], we had discussions with the
Architecture Working Group on how to address this.  We concluded that the
cross-project requirement should not be on Barbican, but on a "Castellan
compatible secret store".  At the time, Barbican was the only choice, but
we wanted to encourage new development.

  We shifted ownership of Castellan (a python key manager abstraction
layer) from the Barbican team to the Oslo team.  The idea was that people
would write Castellan plugins for key managers other than Barbican.  Later
that year, a Castellan plugin for Vault was contributed.[2]  At this time,
the direct-to-vault plugin does not use Keystone for authentication or
oslo.policy for RBAC.  Users can configure the Barbican-to-Vault
architecture if they need to meet those requirements.
   
tl;dr: This vision looks good.  The Castellan and Barbican software
provides abstraction for either the key storage or the key manager, so the
cross project dependency can be "a key manager", instead of specifically
Barbican.

--Dave


[1] https://etherpad.openstack.org/p/barbican-pike-ptg-barbican-discussion
[2] https://review.openstack.org/#/c/483080/


On 10/24/18, 11:16 AM, "Zane Bitter" <zbitter at redhat.com> wrote:

>Greetings, Barbican team!
>As you may be aware, I've been working with other folks in the community
>on documenting a vision for OpenStack clouds (formerly known as the
>'Technical Vision') - essentially to interpret the mission statement in
>long-form, in a way that we can use to actually help guide decisions.
>You can read the latest draft here: https://review.openstack.org/592205
>
>We're trying to get feedback from as many people as possible - in many
>ways the value is in the process of coming together to figure out what
>we're trying to achieve as a community with OpenStack and how we can
>work together to build it. The document is there to help us remember
>what we decided so we don't have to do it all again over and over.
>
>The vision is structured with two sections that apply broadly to every
>project in OpenStack - describing the principles that we believe are
>essential to every cloud, and the ones that make OpenStack different
>from some other clouds. The third section is a list of design goals that
>we want OpenStack as a whole to be able to meet - ideally each project
>would be contributing toward one or more of these design goals.
>
>Barbican provides an abstraction over HSMs and software equivalents
>(like Vault), so the immediate design goal that it meets is the
>'Hardware Virtualisation' one. However, the most interesting part of the
>document for the Barbican team is probably the section on cross-project
>dependencies. In discussions at the PTG, the TC concluded that we
>shouldn't force projects to adopt hard dependencies on other services
>(like Barbican), but recommend that they do so when there is a benefit
>to the user. The challenge here I think is that not duplicating
>security-sensitive code such as secret storage is well known to be
>something that is both of great benefit to the user and highly tempting
>to take a shortcut on. Your feedback on whether we have got the right
>balance is important.
>
>If you would like me or another TC member to join one of your team IRC
>meetings to discuss further what the vision means for your team, please
>reply to this thread to set it up. You are also welcome to bring up any
>questions in the TC IRC channel, #openstack-tc - there's more of us
>around during Office Hours
>(https://governance.openstack.org/tc/#office-hours), but you can talk to
>us at any time.
>
>Feedback can also happen either in this thread or on the review
>https://review.openstack.org/592205
>
>If the team is generally happy with the vision as it is and doesn't have
>any specific feedback, that's cool but I'd like to request that at least
>the PTL leave a vote on the review. It's important to know whether we
>are actually developing a consensus in the community or just talking to
>ourselves :)
>
>many thanks,
>Zane.
>
>__________________________________________________________________________
>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