Open Stack

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.


>
>
>
>  Keystone plays a critical role for us (as it does with every service) in
> authenticating the user to a particular project and storing the roles that
> the user has for that project. Barbican then enforces these restrictions.
> However, keys / secrets are fundamentally divorced from identities in much
> the same way that databases in Trove are, they are owned by a project, not
> a particular user.
>
> Hopefully our thought process makes some sense, let me know if I can
> provide more detail.
>
>
>
> Jarret
>
>
>
>
>
> [1] https://wiki.openstack.org/wiki/Barbican/Incubation
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/653fd388/attachment.html>