<div dir="ltr">Hi Adam,<div><br></div><div>If nothing else, we could always write a "garbage collector" process which periodically scans for shadow containers that are not in use by any listeners anymore and cleans them up. I suppose that's actually not a difficult problem to solve.</div>
<div><br></div><div>Anyway, yes, I'm liking your suggestion quite a bit: It leaves barbican and LBaaS neatly de-coupled, and prevents a ticking time bomb from exploding in the face of a user who deletes a container they didn't know was still in use.</div>
<div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 10, 2014 at 1:19 PM, Adam Harwell <span dir="ltr"><<a href="mailto:adam.harwell@rackspace.com" target="_blank">adam.harwell@rackspace.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;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div>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.</div>
<div>
<div>
<div><br>
</div>
<div><span style="white-space:pre-wrap"></span>--Adam</div>
<div><br>
</div>
</div>
<div><a href="https://keybase.io/rm_you" target="_blank">https://keybase.io/rm_you</a></div>
<div><br>
</div>
</div>
</div>
<div><br>
</div>
<span>
<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>Doug Wiegley <<a href="mailto:dougw@a10networks.com" target="_blank">dougw@a10networks.com</a>><div class=""><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" target="_blank">openstack-dev@lists.openstack.org</a>><br>
</div><span style="font-weight:bold">Date: </span>Tuesday, June 10, 2014 2:53 PM<div><div class="h5"><br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">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></div><div><div class="h5">
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>> 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.)</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>doug</div>
<div><br>
</div>
<div><br>
</div>
<span>
<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>Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</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" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, June 10, 2014 at 1:47 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">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>
<div>
<div>
<div dir="ltr">Adam--
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>What's your proposal for cleaning up copied secrets when they're actually no longer in use by any LB?</div>
<div><br>
</div>
<div>Stephen</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Jun 10, 2014 at 12:04 PM, Adam Harwell <span dir="ltr">
<<a href="mailto:adam.harwell@rackspace.com" target="_blank">adam.harwell@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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><br>
<div>
<div><br>
<br>
<br>
<br>
<br>
On 6/10/14 6:21 AM, "Clark, Robert Graham" <<a href="mailto:robert.clark@hp.com" target="_blank">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" target="_blank">Vijay.Venkatachalam@citrix.com</a><mailto:<a href="mailto:Vijay.Venkatachalam@citrix.com" target="_blank">Vijay.Venkatachalam@citrix.com</a>>><br>
>Reply-To: OpenStack List<br>
><<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.or" target="_blank">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" target="_blank">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.or" target="_blank">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" target="_blank">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" target="_blank">clint@fewbar.com</a><mailto:<a href="mailto:clint@fewbar.com" target="_blank">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" target="_blank">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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" value="+18006134305" target="_blank">(800)613-4305 x807</a><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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" target="_blank">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>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<span></span>Stephen Balukoff <br>
Blue Box Group, LLC <br>
<a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a> </div>
</div>
</div>
</span></div>
</div>
</blockquote>
</div></div></span>
</div>
<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></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>