Users have to be able to delete their secrets from Barbican, it's a fundamental key-management requirement.
> -----Original Message----- > From: Eichberger, German > Sent: 11 June 2014 17:43 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document > on Gerrit > > Sorry, I am late to the party. Holding the shadow copy in the backend is a > fine solution. > > Also, if containers are immutable can they be deleted at all? Can we make a > requirement that a user can't delete a container in Barbican? > > German > > -----Original Message----- > From: Eichberger, German > Sent: Wednesday, June 11, 2014 9:32 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document > on Gerrit > > Hi, > > I think the previous solution is easier for a user to understand. The > referenced container got tampered/deleted we throw an error - but keep > existing load balancers intact. > > With the shadow container we get additional complexity and the user might > be confused where the values are coming from. > > German > > -----Original Message----- > From: Carlos Garza [mailto:carlos.ga...@rackspace.com] > Sent: Tuesday, June 10, 2014 12:18 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document > on Gerrit > > See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican > Neutron LBaaS Integration Ideas. > 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 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 used. > > On Jun 10, 2014, at 12:47 PM, Samuel Bercovici <samu...@radware.com> > wrote: > > > To elaborate on the case where containers get deleted while LBaaS still > references it. > > We think that the following approach will do: > > * The end user can delete a container and leave a "dangling" > reference in LBaaS. > > * 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. > > * 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. > > > > Regards, > > -Sam. > > > > > > From: Evgeny Fedoruk > > Sent: Tuesday, June 10, 2014 2:13 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document > > on Gerrit > > > > Hi All, > > > > Carlos, Vivek, German, thanks for reviewing the RST doc. > > There are some issues I want to pinpoint final decision on them here, in > ML, before writing it down in the doc. > > Other issues will be commented on the document itself. > > > > 1. Support/No support in JUNO > > Referring to summit's etherpad > https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7, > > a. SNI certificates list was decided to be supported. Was decision made > not to support it? > > Single certificate with multiple domains can only partly address the > > need for SNI, still, different applications on back-end will need different > certificates. > > b. Back-end re-encryption was decided to be supported. Was decision > made not to support it? > > c. With front-end client authentication and back-end server > authentication not supported, > > Should certificate chains be supported? > > 2. Barbican TLS containers > > a. TLS containers are immutable. > > b. TLS container is allowed to be deleted, always. > > i. Even when it is used by LBaaS VIP > listener (or other service). > > ii. Meta data on TLS container will > help tenant to understand that container is in use by LBaaS service/VIP > listener > > 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? > > > > Please comment on these points and review the document on gerrit > > (https://review.openstack.org/#/c/98640) > > I will update the document with decisions on above topics. > > > > Thank you! > > Evgeny > > > > > > From: Evgeny Fedoruk > > Sent: Monday, June 09, 2014 2:54 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document on > > Gerrit > > > > Hi All, > > > > A Spec. RST document for LBaaS TLS support was added to Gerrit for > > review > > https://review.openstack.org/#/c/98640 > > > > You are welcome to start commenting it for any open discussions. > > I tried to address each aspect being discussed, please add comments > about missing things. > > > > Thanks, > > Evgeny > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev