<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 4:48 PM, Morgan Fainberg <span dir="ltr"><<a href="mailto:m@metacloud.com" target="_blank">m@metacloud.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">

<span style="color:rgb(160,160,168)">On December 12, 2013 at 14:32:36, Dolph Mathews (</span><a href="mailto://dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a><span style="color:rgb(160,160,168)">) wrote:</span></div>

 <div><div><blockquote type="cite" style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:start;font-style:normal;font-weight:normal;line-height:normal;text-transform:none;font-size:13px;white-space:normal;font-family:Helvetica,Arial;word-spacing:0px">

<span><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br>On Thu, Dec 12, 2013 at 2:58 PM, Adam Young<span> </span><span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span><span> </span>wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div><div>On 12/04/2013 08:58 AM, Jarret Raim wrote:<br>

</div><blockquote type="cite"><blockquote type="cite"><pre>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.
</pre></blockquote><pre>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.
</pre></blockquote><br></div></div>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. <br>

<br>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.<br></div></blockquote>
<div>
<br></div><div>/me puts PTL hat on</div><div><br></div><div>++ I don't want Russel's job.</div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div> </div></div></div></div></div></div></span></blockquote></div></div></div></div><p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.  </p>

<p>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.</p><p>Dolph: (disclaimer) I’m not trying to convince people you should have Russell’s job (or wear a hat similar in size to his).</p>

<p>Cheers,</p><p>Morgan Fainberg</p></div></blockquote></div><div>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.</div>

<div><br></div>-Dolph
</div></div>