<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>
<div>
<div>Comments inline.</div>
<div>
<div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>--Adam</div>
<div><br>
</div>
</div>
<div><a href="https://keybase.io/rm_you">https://keybase.io/rm_you</a></div>
<div><br>
</div>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Evgeny Fedoruk <<a href="mailto:EvgenyF@Radware.com">EvgenyF@Radware.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, June 11, 2014 9:31 AM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Arial Unicode MS";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@Arial Unicode MS";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1987008919;
mso-list-type:hybrid;
mso-list-template-ids:-975034402 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Regarding the case when back-end system tries to retrieve secret from deleted Barbican TLS container,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Is this a real use case? I mean, is there a back-end system which will get container ID from somewhere, try to retrieve secrets from Barbican by
itself and hope for good?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">In my understanding, there is a plugin and a driver who can always check TLS container existence before even start configuring the back-end system.
In case of a problem tenant will receive a clear error message and back-end system will remain up and running.</span></p>
</div>
</div>
</div>
</blockquote>
</span>
<div>The issue is when this happens well after any user interaction, when the LB has already been up and running and the user could be asleep or out of the country or any number of things that would prevent them from dealing with the issue in a timely manner,
if they even became aware of it immediately (depending on how good our alerting is). See below.</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">In case when back-end system itself triggers secret retrieval (outside of OpenStack scope) – first it should check container existence and only
after that destroy previous TLS setup and perform a new setup.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">LBaaS back-end system may not get a container ID at all, but get its content and not interact with Barbican by itself.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">In case when new LBaaS back-end system is created (HA event, for example), whoever created an instance and gave it container ID, should check its
existence.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Is there a specific use case when:<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">back-end system, having container ID, up and running, offloading encrypted traffic with a certificate from that container
(by this time deleted from Barbican),<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:.5in"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">at some time, goes and tries to retrieve the secret, fails, loses its previous TLS settings and causing downtime?</span></p>
</div>
</div>
</div>
</blockquote>
</span>
<div>Yes, the case is basically what you said — there is a running LB using SSL termination, that LB becomes unreachable (for whatever reason) and we need to do a failover and create a new instance, we would need to retrieve the certificate to do so, the retrieval
would fail, and now there is no reachable LB because our HA mechanism broke during provisioning a new device. I don't see this as a theoretical, I see this as something with a 100% chance of happening.</div>
<div><br>
</div>
<div>That said, the more I think about the interaction between neutron-lbaas, Barbican, and the driver/backend, the more I think this is not an issue we need to discuss here. It's really an issue for our Service-VM-haproxy system (I think people are calling
it Octavia) and not a problem for neutron-lbaas itself, as I admitted in previous mails. I agree that probably the driver/backend will never even GET the barbican ContainerID, in which case shadow-copy is essentially the most sane option (and is essentially
what every other service is doing in the backend too, it just happens that our storage mechanism is
<span style="font-weight: bold; ">also</span> Barbican). I think we are mostly in agreement here. :)</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Regards,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Evgeny<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "> Vijay Venkatachalam [<a href="mailto:Vijay.Venkatachalam@citrix.com">mailto:Vijay.Venkatachalam@citrix.com</a>]
<br>
<b>Sent:</b> Wednesday, June 11, 2014 4:14 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> [Caution: Message contains Suspicious URL content] Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">+1 – Warning on a deletion of certificate in use can be considered as a “nice-to-have” feature and not “must-have”!</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">From:</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; "> Samuel Bercovici [<a href="mailto:SamuelB@Radware.com">mailto:SamuelB@Radware.com</a>]
<br>
<b>Sent:</b> Wednesday, June 11, 2014 4:16 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Hi,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">For Juno -</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I think that the existing capabilities in Barbican should be enough to start with.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">A good detection and error message in LBaaS should also be sufficient to start with.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">After Juno -
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">We can consider a fix enhancement to Barbican later, IF deleting a certificate in use and expressing an explicit error, will be common and become
an issue.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> -Sam.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "> Doug Wiegley [<a href="mailto:dougw@a10networks.com">mailto:dougw@a10networks.com</a>]
<br>
<b>Sent:</b> Wednesday, June 11, 2014 12:41 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> [Caution: Message contains Suspicious URL content] Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Of what use is a database that randomly delete rows? That is, in effect, what you’re allowing.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family: Calibri, sans-serif; ">The secrets are only useful when paired with a service. And unless I’m mistaken, there’s no undo. So you’re letting users shoot themselves in the foot, for what reason, exactly? How do
you expect openstack to rely on a data store that is fundamentally random at the whim of users? Every single service that uses Barbican will now have to hack in a defense mechanism of some kind, because they can’t trust that the secret they rely on will still
be there later. Which defeats the purpose of this mission statement: "</span><span style="font-family: 'Arial Unicode MS', sans-serif; color: rgb(51, 51, 51); background-color: white; background-position: initial initial; background-repeat: initial initial; ">Barbican
is a ReST API designed for the secure storage, provisioning and management of secrets.”</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">(And I don’t think anyone is suggesting that blind refcounts are the answer. At least, I hope not.)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Anyway, I hear this has already been decided, so, so be it. Sounds like we’ll hack around it.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Thanks,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">doug</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">From:
</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">Douglas Mendizabal <<a href="mailto:douglas.mendizabal@RACKSPACE.COM">douglas.mendizabal@RACKSPACE.COM</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Tuesday, June 10, 2014 at 3:26 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">I think that having Barbican decide whether the user is or isn’t allowed to delete a secret that they own based on a reference count that is not directly
controlled by them is unacceptable. This is indeed policy enforcement, and we’d rather not go down that path.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">I’m opposed to the idea of reference counting altogether, but a couple of other Barbican-core members are open to it, as long as it does not affect the delete
behaviors.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">-Doug M.</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">From:
</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">Adam Harwell <<a href="mailto:adam.harwell@RACKSPACE.COM">adam.harwell@RACKSPACE.COM</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Tuesday, June 10, 2014 at 4:17 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Doug: Right, we actually have a blueprint draft for EXACTLY this, but the Barbican team gave us a flat "not happening, we reject this change" on causing a
delete to fail. The shadow-copy solution I proposed only came about because the option you are proposing is not possible. :(</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">I also realized that really, this whole thing is an issue for the backend, not really for the API itself — the LBaaS API will be retrieving the key/cert from
Barbican and passing it to the backend, and the backend it what's responsible for handling it from that point (F5, Stingray etc would never actually call back to Barbican). So, really, the Service-VM solution we're architecting is where the shadow-copy solution
needs to live, at which point it no longer is really an issue we'd need to discuss on this mailing list, I think. Stephen, does that make sense to you?</span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">--Adam</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><a href="https://keybase.io/rm_you">https://keybase.io/rm_you</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">From:
</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">Doug Wiegley <<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Tuesday, June 10, 2014 4:10 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">A third option, that is neither shadow copying nor policy enforcement:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Ask the Barbican team to put in a small api that is effectively, “hey, I’m using this container” and “hey, I’m done with this container”, and the have their
delete fail if someone is still using it. This isn’t calling into other services, it’s simply getting informed of who’s using what, and not stomping it. That seems pretty core to me, and the workarounds if we can’t trust the store to store things are pretty
hacky.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Doug</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">From:
</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">Adam Harwell <<a href="mailto:adam.harwell@RACKSPACE.COM">adam.harwell@RACKSPACE.COM</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Tuesday, June 10, 2014 at 3:04 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Right, service VMs are the biggest case for this, because then we WILL need to be tracking the barbicanID even in the backend. I also agree that it would
be more useful for OpenStack as a whole if it were managed by a central service (i.e., Barbican handles this issue) rather than having to duplicate all of this logic in every service that utilizes the containers (VPN/FW would have to use essentially the same
strategy, or else fragment and do something entirely different — the first of which is a lot of duplicated effort, and the second is just generally bad, already way too much fragmentation going on). On the other hand, the Barbican team is very opposed to doing
policy enforcement within Barbican, and I can't say I fault them for that opinion (Barbican was never designed to include a policy enforcement engine). The shadow-copy strategy is the best alternative I can think of given the current project/political landscape.
:(</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">--Adam</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><a href="https://keybase.io/rm_you">https://keybase.io/rm_you</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">From:
</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">Doug Wiegley <<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Tuesday, June 10, 2014 3:42 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">> Doug: The reasons a LB might be reprovisioned are fairly important — mostly around HA, for fail overs or capacity — exactly the times we're trying avoid
a failure.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Certainly the ticking time bomb is a bad idea, but HA seems cleaner to do in the backend, rather than at the openstack API level (the dangling reference doesn’t
kick in until the lbaas api is used to accomplish that failover.) And the lbaas api also doesn’t have any provisions for helping to shuffle for capacity, so that also becomes a backend issue. And the backend won’t be natively dealing with a barbican reference.</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">However, couple this with service VM’s, and I guess the issue pops back into the forefront. This is going to be an issue that everyone using ssl certs in
barbican is going to have, so it seems we’re applying a band-aid in the wrong place.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Doug</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">From:
</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">Adam Harwell <<a href="mailto:adam.harwell@RACKSPACE.COM">adam.harwell@RACKSPACE.COM</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Tuesday, June 10, 2014 at 2:19 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Doug: The reasons a LB might be reprovisioned are fairly important — mostly around HA, for fail overs or capacity — exactly the times we're trying avoid a
failure.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Stephen: yes, I am talking about storing the copy in a non-tenant way (on the tenant-id for the LBaaS Service Account, not visible to the user). We would
have to delete our shadow-copy when the loadbalancer was updated with a new barbicanID by the user, and make a copy of the new container to take its place.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Also, yes, I think it would be quite surprising (and far from ideal) when the LB you set up breaks weeks or months later when an HA event occurs and you haven't
actually made any "changes" in quite a long time. Unfortunately, "making the key unusable in all other contexts" on a Barbican delete isn't really an option, so this is the best fallback I can think of.</span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">--Adam</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><a href="https://keybase.io/rm_you">https://keybase.io/rm_you</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">From:
</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">Doug Wiegley <<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Tuesday, June 10, 2014 2:53 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">> In any case, it strikes me as misleading to have an explicit delete command sent to Barbican not have the effect of making the key unusable in all other
contexts. It would be less surprising behavior, IMO, to have a deleted barbican container result in connected load balancing services breaking. (Though without notification to LBaaS, the connected service might break weeks or months after the key disappeared
from barbican, which would be more surprising behavior.)</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Since a delete in barbican will not affect neutron/lbaas, and since most backends will have had to make their own copy of the key at lb provision time, the
barbican delete will not result in lbaas breaking, I think. The shadow copy would only get used if the lb had to be re-provisioned for some reason before it was given a new key id, which seems a fair bit of complexity for what is gained.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">doug</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">From:
</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Tuesday, June 10, 2014 at 1:47 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Adam--
</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Wouldn't the user see the duplicate key/cert copy in their barbican interface, or are you proposing storing these secrets in a not-assigned-to-the-tenant
kind of way?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">In any case, it strikes me as misleading to have an explicit delete command sent to Barbican not have the effect of making the key unusable in all other contexts.
It would be less surprising behavior, IMO, to have a deleted barbican container result in connected load balancing services breaking. (Though without notification to LBaaS, the connected service might break weeks or months after the key disappeared from barbican,
which would be more surprising behavior.)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Personally, I like your idea, as I think most of our users would rather have LBaaS issue warnings when the user has done something stupid like this rather
than break entirely. I know our support staff would rather it behaved this way.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">What's your proposal for cleaning up copied secrets when they're actually no longer in use by any LB?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Stephen</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">On Tue, Jun 10, 2014 at 12:04 PM, Adam Harwell <<a href="mailto:adam.harwell@rackspace.com" target="_blank">adam.harwell@rackspace.com</a>> wrote:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">So, it looks like any sort of validation on Deletes in Barbican is going<br>
to be a no-go. I'd like to propose a third option, which might be the<br>
safest route to take for LBaaS while still providing some of the<br>
convenience of using Barbican as a central certificate store. Here is a<br>
diagram of the interaction sequence to create a loadbalancer:<br>
<a href="http://bit.ly/1pgAC7G" target="_blank">http://bit.ly/1pgAC7G</a><br>
<br>
Summary: Pass the Barbican "TLS Container ID" to the LBaaS create call,<br>
get the container from Barbican, and store a "shadow-copy" of the<br>
container again in Barbican, this time on the LBaaS service account.<br>
The secret will now be duplicated (it still exists on the original tenant,<br>
but also exists on the LBaaS tenant), but we're not talking about a huge<br>
amount of data here -- just a few kilobytes. With this approach, we retain<br>
most of the advantages we wanted to get from using Barbican -- we don't<br>
need to worry about taking secret data through the LBaaS API (we still<br>
just take a barbicanID from the user), and the user can still use a single<br>
barbicanID (the original one they created -- the copies are invisible to<br>
them) when passing their TLS info to other services. We gain the<br>
additional advantage that it no longer matters what happens to the<br>
original TLS container -- it could be deleted and it would not impact our<br>
service.<br>
<br>
What do you guys think of that option?<br>
<br>
<br>
<br>
As an addendum (not saying we necessarily want to do this, but it's an<br>
option), we COULD retain both the original and the copied barbicanID in<br>
our database and attempt to fetch them in that order when we need the TLS<br>
info again, which would allow us to do some alerting if the user does<br>
delete their key. For example: the user has deleted their key because it<br>
was compromised, but they forgot they used it on their loadbalancer -> a<br>
failover event occurs and we attempt to fetch the info from Barbican -><br>
the first fetch fails, but the second fetch to our copy succeeds -> the<br>
failover of the LB is successful, and we send an alert to notify the user<br>
that their LB is using TLS info that has been deleted from Barbican.<br>
<br>
<br>
--Adam<br>
<br>
<br>
<a href="https://keybase.io/rm_you" target="_blank">https://keybase.io/rm_you</a></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><br>
<br>
<br>
<br>
<br>
On 6/10/14 6:21 AM, "Clark, Robert Graham" <<a href="mailto:robert.clark@hp.com">robert.clark@hp.com</a>> wrote:<br>
<br>
>It looks like this has come full circle and we are back at the simplest<br>
>case.<br>
><br>
># Containers are immutable<br>
># Changing a cert means creating a new container and, when ready,<br>
>pointing LBaaS at the new container<br>
><br>
>This makes a lot of sense to me, it removes a lot of handholding and<br>
>keeps Barbican and LBaaS nicely decoupled. It also keeps certificate<br>
>lifecycle management firmly in the hands of the user, which imho is a<br>
>good thing. With this model it¹s fairly trivial to provide guidance /<br>
>additional tooling for lifecycle management if required but at the same<br>
>time the simplest case (I want a cert and I want LBaaS) is met without<br>
>massive code overhead for edge-cases.<br>
><br>
><br>
>From: Vijay Venkatachalam<br>
><<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a><mailto:<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>>><br>
>Reply-To: OpenStack List<br>
><<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.or">openstack-dev@lists.openstack.or</a><br>
>g>><br>
>Date: Tuesday, 10 June 2014 05:48<br>
>To: OpenStack List<br>
><<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.or">openstack-dev@lists.openstack.or</a><br>
>g>><br>
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS<br>
>Integration Ideas<br>
><br>
><br>
>My vote is for option #2 (without the registration). It is simpler to<br>
>start with this approach. How is delete handled though?<br>
><br>
>Ex. What is the expectation when user attempts to delete a<br>
>certificate/container which is referred by an entity like LBaaS listener?<br>
><br>
><br>
>1. Will there be validation in Barbican to prevent this? *OR*<br>
><br>
>2. LBaaS listener will have a dangling reference/pointer to<br>
>certificate?<br>
><br>
>Thanks,<br>
>Vijay V.<br>
><br>
>From: Stephen Balukoff [mailto:<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>]<br>
>Sent: Tuesday, June 10, 2014 7:43 AM<br>
>To: OpenStack Development Mailing List (not for usage questions)<br>
>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS<br>
>Integration Ideas<br>
><br>
>Weighing in here:<br>
><br>
>I'm all for option #2 as well.<br>
><br>
>Stephen<br>
><br>
>On Mon, Jun 9, 2014 at 4:42 PM, Clint Byrum<br>
><<a href="mailto:clint@fewbar.com">clint@fewbar.com</a><mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>>> wrote:<br>
>Excerpts from Douglas Mendizabal's message of 2014-06-09 16:08:02 -0700:<br>
>> Hi all,<br>
>><br>
>> I¹m strongly in favor of having immutable TLS-typed containers, and very<br>
>> much opposed to storing every revision of changes done to a container.<br>
>>I<br>
>> think that storing versioned containers would add too much complexity to<br>
>> Barbican, where immutable containers would work well.<br>
>><br>
>Agree completely. Create a new one for new values. Keep the old ones<br>
>while they're still active.<br>
><br>
>><br>
>> I¹m still not sold on the idea of registering services with Barbican,<br>
>>even<br>
>> though (or maybe especially because) Barbican would not be using this<br>
>>data<br>
>> for anything. I understand the problem that we¹re trying to solve by<br>
>> associating different resources across projects, but I don¹t feel like<br>
>> Barbican is the right place to do this.<br>
>><br>
>Agreed also, this is simply not Barbican or Neutron's role. Be a REST<br>
>API for secrets and networking, not all dancing all singing nannies that<br>
>prevent any possibly dangerous behavior with said API's.<br>
><br>
>> It seems we¹re leaning towards option #2, but I would argue that<br>
>> orchestration of services is outside the scope of Barbican¹s role as a<br>
>> secret-store. I think this is a problem that may need to be solved at a<br>
>> higher level. Maybe an openstack-wide registry of dependend entities<br>
>> across services?<br>
>An optional openstack-wide registry of depended entities is called<br>
>"Heat".<br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
>--<br>
>Stephen Balukoff<br>
>Blue Box Group, LLC<br>
><a href="tel:%28800%29613-4305%20x807">(800)613-4305 x807</a><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><br>
<br clear="all">
</span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "> </span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">--
<br>
Stephen Balukoff <br>
Blue Box Group, LLC <br>
(800)613-4305 x807 </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>