On Thu, Dec 12, 2013 at 4:48 PM, Morgan Fainberg <m...@metacloud.com> wrote:
> On December 12, 2013 at 14:32:36, Dolph Mathews > (dolph.math...@gmail.com<//dolph.math...@gmail.com>) > wrote: > > > On Thu, Dec 12, 2013 at 2:58 PM, Adam Young <ayo...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
