[openstack-dev] Incubation Request for Barbican

Dolph Mathews dolph.mathews at gmail.com
Thu Dec 19 19:05:06 UTC 2013


On Thu, Dec 12, 2013 at 4:48 PM, Morgan Fainberg <m at metacloud.com> wrote:

> On December 12, 2013 at 14:32:36, Dolph Mathews (dolph.mathews at gmail.com<//dolph.mathews at gmail.com>)
> wrote:
>
>
> On Thu, Dec 12, 2013 at 2:58 PM, Adam Young <ayoung at redhat.com> wrote:
>
>> On 12/04/2013 08:58 AM, Jarret Raim wrote:
>>
>> While I am all for adding a new program, I think we should only add one
>> if we
>> rule out all existing programs as a home. With that in mind why not add
>> this
>> to the  keystone program? Perhaps that may require a tweak to keystones
>> mission
>> statement, but that is doable. I saw a partial answer to this somewhere
>> but not a full one.
>>
>> From our point of view, Barbican can certainly help solve some problems
>> related to identity like SSH key management and client certs. However,
>> there is a wide array of functionality that Barbican will handle that is
>> not related to identity.
>>
>>
>> Some examples, there is some additional detail in our application if you
>> want to dig deeper [1].
>>
>>
>> * Symmetric key management - These keys are used for encryption of data at
>> rest in various places including Swift, Nova, Cinder, etc. Keys are
>> resources that roll up to a project, much like servers or load balancers,
>> but they have no direct relationship to an identity.
>>
>> * SSL / TLS certificates - The management of certificate authorities and
>> the issuance of keys for SSL / TLS. Again, these are resources rather than
>> anything attached to identity.
>>
>> * SSH Key Management - These could certainly be managed through keystone
>> if we think that¹s the right way to go about it, but from Barbican¹s point
>> of view, these are just another type of a key to be generated and tracked
>> that roll up to an identity.
>>
>>
>> * Client certificates - These are most likely tied to an identity, but
>> again, just managed as resources from a Barbican point of view.
>>
>> * Raw Secret Storage - This functionality is usually used by applications
>> residing on an Cloud. An app can use Barbican to store secrets such as
>> sensitive configuration files, encryption keys and the like. This data
>> belongs to the application rather than any particular user in Keystone.
>> For example, some Rackspace customers don¹t allow their application dev /
>> maintenance teams direct access to the Rackspace APIs.
>>
>> * Boot Verification - This functionality is used as part of the trusted
>> boot functionality for transparent disk encryption on Nova.
>>
>> * Randomness Source - Barbican manages HSMs which allow us to offer a
>> source of true randomness.
>>
>>
>>
>> In short (ha), I would encourage everyone to think of keys / certificates
>> as resources managed by an API in much the same way we think of VMs being
>> managed by the Nova API. A consumer of Barbican (either as an OpenStack
>> service or a consumer of an OpenStack cloud) will have an API to create
>> and manage various types of secrets that are owned by their project.
>>
>>
>> My reason for keeping them separate is more practical:  the Keystone team
>> is already somewhat overloaded.  I know that a couple of us have interest
>> in contributing to Barbican, the question is time and prioritization.
>>
>> Unless there is some benefit to having both projects in the same program
>> with essentially different teams, I think Barbican should proceed as is.  I
>> personally plan on contributing to Barbican.
>>
>
> /me puts PTL hat on
>
> ++ I don't want Russel's job.
>
> Keystone has a fairly narrow mission statement in my mind (come to think
> of it, I need to propose it to governance..), and that's basically to
> abstract away the problem of authenticating and authorizing the API users
> of other openstack services. Everything else, including identity
> management, key management, key distribution, quotas, etc, is just
> secondary fodder that we tend to help with along the way... but they should
> be first class problems in someone else's mind.
>
> If we rolled everything together that kind of looks related to keystone
> under a big keystone program for the sake of organizational tidiness, I
> know I would be less effective as a "PTL" and that's a bit disheartening.
> That said, I'm always happy to help where I can.
>
>
> The long and the short of it is that I can’t argue that Barbican couldn’t
> be considered a mechanism of “Identity” (in most everything keys end up
> being a form of Identity, and the management of that would fit nicely under
> the “Identity Program”).  That being said I also can’t argue that Barbican
> shouldn’t be it’s own top-level program.  It comes down to the best fit for
> OpenStack as a whole.
>
> From a deployer standpoint, I don’t think it will make any real difference
> if Barbican is in Identity or it’s own program.  Basically, it’ll be a
> separate process to run in either case.  It will have it’s own rules and
> quirks.
>
> From a developer standpoint, I don’t think it will make a significant
> difference (besides, perhaps where documentation lies).  The contributors
> to Keystone will contribute (or not) to Barbican and vice-versa based upon
> interest/time/needs.
>
> From a community and communication standpoint (which is the important part
> here), I think it comes down to messaging and what Barbican is meant to be.
>  If we are happy messaging that it is a separate project, with separate
> rules, and a separate team looking at it, I think it can be built up into
> it’s own program.  However, if there are any questions to the veracity of
> the claims above (or about the assumptions made in this paragraph), I think
> it needs to be looked at closely as to if Keystone (sorry, “Identity”) is
> the right place to put Barbican.
>
> In reality, I think that as it stands Barbican could become it’s own
> program; future looking me is not sure, which is why I am having a hard
> time arguing for either side.
>
> Dolph: (disclaimer) I’m not trying to convince people you should have
> Russell’s job (or wear a hat similar in size to his).
>
> Cheers,
>
> Morgan Fainberg
>
Belatedly catching up here... but I share Morgan's opinion/perspective
completely. I feel like we're trying to predict (and maybe dictate?)
community dynamics before they've had a chance to naturally develop.
Regardless of what program it lands in, if Barbican is blessed by OpenStack
as an incubated project, I think we'll see more obvious answers to the
questions / concerns expressed in this thread come graduation time.

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131219/57de439a/attachment.html>


More information about the OpenStack-dev mailing list