<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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
cite="mid:1A3C52DFCD06494D8528644858247BF01B91A9D5@EX10MBOX03.pnnl.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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
moz-do-not-send="true" href="mailto:dolph.mathews@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a></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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:hongbin.lu@huawei.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a></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
moz-do-not-send="true"
href="https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-store"
target="_blank">
<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></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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br>
<span><a moz-do-not-send="true"
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 wrap="">__________________________________________________________________________
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>
</body>
</html>