<div dir="ltr">I responded in the other thread just now, but I did want to say:<div><br></div><div>The problem with a dangling reference is this might mean that the associated Listener breaks at some random time after the barbican container goes away. While this is "intuitive" and "expected" behavior if it happens shortly after the barbican container disappears, I think it would be very unexpected if it happens weeks or months after the barbican container goes away (and would probably result in a troubleshooting nightmare). Having had to deal with many of these in the course of my career, I really dislike "ticking time bombs" like this, so I'm starting to be convinced that the approach Adam Harwell recommended in the other thread (ie. keep shadow copies of containers) is probably the most graceful way to handle dangling references, even if it does mean that when a user deletes a container, it isn't really gone "yet."</div>
<div><br></div><div>So! If we're not going to tie into an eventing or notification system which would cause a Listener to break immediately after a connected barbican container is deleted, then I think Adam's approach is the next best alternative.</div>
<div><br></div><div>Also: Samuel: I agree that it would be great to be able to add meta-data so that the user can be made easily aware of which of their barbican containers are in use by LBaaS listeners.</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:17 PM, Carlos Garza <span dir="ltr"><<a href="mailto:carlos.garza@rackspace.com" target="_blank">carlos.garza@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas.<br>
He's advocating keeping a shadow copy of the private key that is owned by the LBaaS service so that incase a key is tampered with during an<br>
LB update migration etc we can still check with the shadow backup and compare it to the user owned TLS container in case its not their it can be<br>
used.<br>
<br>
On Jun 10, 2014, at 12:47 PM, Samuel Bercovici <SamuelB@Radware.com><br>
<div class="HOEnZb"><div class="h5"> wrote:<br>
<br>
> To elaborate on the case where containers get deleted while LBaaS still references it.<br>
> We think that the following approach will do:<br>
> · The end user can delete a container and leave a “dangling” reference in LBaaS.<br>
> · It would be nice to allow adding meta data on the container so that the user will be aware which listeners use this container. This is optional. It can also be optional for LBaaS to implement adding the listeners ID automatically into this metadata just for information.<br>
> · In LBaaS, if an update happens which requires to pull the container from Barbican and if the ID references a non-existing container, the update will fail and will indicate that the reference certificate does not exists any more. This validation could be implemented on the LBaaS API itself as well as also by the driver who will actually need the container.<br>
><br>
> Regards,<br>
> -Sam.<br>
><br>
><br>
> From: Evgeny Fedoruk<br>
> Sent: Tuesday, June 10, 2014 2:13 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit<br>
><br>
> Hi All,<br>
><br>
> Carlos, Vivek, German, thanks for reviewing the RST doc.<br>
> There are some issues I want to pinpoint final decision on them here, in ML, before writing it down in the doc.<br>
> Other issues will be commented on the document itself.<br>
><br>
> 1. Support/No support in JUNO<br>
> Referring to summit’s etherpad <a href="https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7" target="_blank">https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7</a>,<br>
> a. SNI certificates list was decided to be supported. Was decision made not to support it?<br>
> Single certificate with multiple domains can only partly address the need for SNI, still, different applications<br>
> on back-end will need different certificates.<br>
> b. Back-end re-encryption was decided to be supported. Was decision made not to support it?<br>
> c. With front-end client authentication and back-end server authentication not supported,<br>
> Should certificate chains be supported?<br>
> 2. Barbican TLS containers<br>
> a. TLS containers are immutable.<br>
> b. TLS container is allowed to be deleted, always.<br>
> i. Even when it is used by LBaaS VIP listener (or other service).<br>
> ii. Meta data on TLS container will help tenant to understand that container is in use by LBaaS service/VIP listener<br>
> iii. If every VIP listener will “register” itself in meta-data while retrieving container, how that “registration” will be removed when VIP listener stops using the certificate?<br>
><br>
> Please comment on these points and review the document on gerrit (<a href="https://review.openstack.org/#/c/98640" target="_blank">https://review.openstack.org/#/c/98640</a>)<br>
> I will update the document with decisions on above topics.<br>
><br>
> Thank you!<br>
> Evgeny<br>
><br>
><br>
> From: Evgeny Fedoruk<br>
> Sent: Monday, June 09, 2014 2:54 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit<br>
><br>
> Hi All,<br>
><br>
> A Spec. RST document for LBaaS TLS support was added to Gerrit for review<br>
> <a href="https://review.openstack.org/#/c/98640" target="_blank">https://review.openstack.org/#/c/98640</a><br>
><br>
> You are welcome to start commenting it for any open discussions.<br>
> I tried to address each aspect being discussed, please add comments about missing things.<br>
><br>
> Thanks,<br>
> Evgeny<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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><br>
</div></div></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>