<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Kevin,<br>
<br>
I understand that this is how it is now. My question is how bad
would it be to wrap the Barbican client library calls in another
class and claim, for all practical purposes, that Magnum has no
direct dependency on Barbican? What is the negative of doing that? <br>
<br>
Anyone who wants to use another mechanism should be able to do that
with a simple change to the Magnum conf file. Nothing more
complicated. That's the essence of my question.<br>
<br>
Appreciate your thoughts and insight.<br>
<br>
Reza<br>
<br>
<div class="moz-cite-prefix">On 4/13/2016 6:46 AM, Fox, Kevin M
wrote:<br>
</div>
<blockquote
cite="mid:1A3C52DFCD06494D8528644858247BF01B91AE6D@EX10MBOX03.pnnl.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Barbican is the abstraction layer. Its plugable like nova,
neutron, cinder, etc.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font color="#000000" size="2" face="Tahoma"> </font></div>
</strong>
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> rezroo<br>
<b>Sent:</b> Tuesday, April 12, 2016 11:00:30 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<b>Subject:</b> Re: [openstack-dev] [magnum][keystone][all]
Using Keystone /v3/credentials to store TLS certificates<br>
</font><br>
<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
moz-do-not-send="true" class="moz-txt-link-abbreviated"
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"
class="moz-txt-link-abbreviated"
href="mailto:hongbin.lu@huawei.com"><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><a moz-do-not-send="true"
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 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>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a moz-do-not-send="true" 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 moz-do-not-send="true" 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>
<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>