<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body bgcolor="#FFFFFF">
Barbican is the abstraction layer. Its plugable like nova, neutron, cinder, etc.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> rezroo<br>
<b>Sent:</b> Tuesday, April 12, 2016 11:00:30 PM<br>
<b>To:</b> openstack-dev@lists.openstack.org<br>
<b>Subject:</b> Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates<br>
</font><br>
<div></div>
<div>Interesting conversation, and I think I have more of a question than a comment. With my understanding of OpenStack architecture, I don't understand the point about making "Magnum dependent on Barbican". Wouldn't this issue be completely resolved using
a driver model, such as delegating the task to a separate class specified in magnum.conf, with a reference implementation using Barbian API (like the vif driver of nova, or nova chance vs. filter scheduler)? If people want choice, we know how to give them
choice - decouple, and have a base implementation. The rest is up to them. That's the framework's architecture. What am I missing?<br>
Thanks,<br>
Reza<br>
<br>
<div class="moz-cite-prefix">On 4/12/2016 9:16 PM, Fox, Kevin M wrote:<br>
</div>
<blockquote type="cite">Ops are asking for you to make it easy for them to make their security weak. And as a user of other folks clouds, i'd have no way to know the cloud is in that mode. That seems really bad for app developers/users.<br>
<br>
Barbican, like some of the other servises, wont become common if folks keep trying to reimplement it so they dont have to depend on it. Folks said the same things about Keystone. Ultimately it was worth making it a dependency.<br>
<br>
Keystone doesnt support encryption, so you are asking for new functionality duplicating Barbican either way.<br>
<br>
And we do understand the point of what you are trying to do. We just dont see eye to eye on it being a good thing to do. If you are invested enough in setting up an ha setup where you would need a clusterd solution, barbicans not that much of an extra lift
compared to the other services you've already had to deploy. Ive deployed both ha setups and barbican before. Ha is way worse.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<strong>
<div><font color="#000000" size="2" face="Tahoma"> </font></div>
</strong>
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> Adrian Otto<br>
<b>Sent:</b> Tuesday, April 12, 2016 8:06:03 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates<br>
</font><br>
<div>
<div>Please don't miss the point here. We are seeking a solution that allows a location to place a client side encrypted blob of data (A TLS cert) that multiple magnum-conductor processes on different hosts can reach over the network. </div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">We *already* support using Barbican for this purpose, as well as storage in flat files (not as secure as Barbican, and only works with a single conductor) and are seeking a second alternative for clouds that have not yet adopted
Barbican, and want to use multiple conductors. Once Barbican is common in OpenStack clouds, both alternatives are redundant and can be deprecated. If Keystone depends on Barbican, then we have no reason to keep using it. That will mean that Barbican is core
to OpenStack.</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">Our alternative to using Keystone is storing the encrypted blobs in the Magnum database which would cause us to add an API feature in magnum that is the exact functional equivalent of the credential store in Keystone. That is something
we are trying to avoid by leveraging existing OpenStack APIs.<br>
<br>
--
<div>Adrian</div>
</div>
<div><br>
On Apr 12, 2016, at 3:44 PM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com"></a><a class="moz-txt-link-abbreviated" href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad <span dir="ltr">
<<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>></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 dir="ltr">Keystone's credential API pre-dates barbican. We started talking about having the credential API back to barbican after it was a thing. I'm not sure if any work has been done to move the credential API in this direction. From a security perspective,
I think it would make sense for keystone to back to barbican.</div>
</blockquote>
<div><br>
</div>
<div>+1</div>
<div><br>
</div>
<div>And regarding the "inappropriate use of keystone," I'd agree... without this spec, keystone is entirely useless as any sort of alternative to Barbican:</div>
<div><br>
</div>
<div> <a href="https://review.openstack.org/#/c/284950/">https://review.openstack.org/#/c/284950/</a></div>
<div><br>
</div>
<div>I suspect Barbican will forever be a much more mature choice for Magnum.</div>
<div> </div>
<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 class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div class="h5">On Tue, Apr 12, 2016 at 2:43 PM, Hongbin Lu <span dir="ltr"><<a href="mailto:hongbin.lu@huawei.com" target="_blank"></a><a class="moz-txt-link-abbreviated" href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>></span> wrote:<br>
</div>
</div>
<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>
<div class="h5">
<div lang="EN-CA">
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Hi all,</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">In short, some Magnum team members proposed to store TLS certificates in Keystone credential store. As Magnum PTL, I want to get agreements (or non-disagreement) from OpenStack community in general, Keystone
community in particular, before approving the direction.</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">In details, Magnum leverages TLS to secure the API endpoint of kubernetes/docker swarm. The usage of TLS requires a secure store for storing TLS certificates. Currently, we leverage Barbican for this purpose,
but we constantly received requests to decouple Magnum from Barbican (because users normally don’t have Barbican installed in their clouds). Some Magnum team members proposed to leverage Keystone credential store as a Barbican alternative [1]. Therefore, I
want to confirm what is Keystone team position for this proposal (I remembered someone from Keystone mentioned this is an inappropriate use of Keystone. Would I ask for further clarification?). Thanks in advance.</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">[1] <a href="https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-store" target="_blank">
</a><a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-store">https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-store</a>
</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Best regards,</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Hongbin</span></p>
</div>
</div>
<br>
</div>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>__________________________________________________________________________</span><br>
<span>OpenStack Development Mailing List (not for usage questions)</span><br>
<span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset> <br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
</body>
</html>