>From an LBaaS view we have two use cases we access the certs: 1) When a new LB is build, an LB is changed, etc. -- we throw an error if the certificate is missing, broken, etc,
2) When we want to failover -- we use the last good certificate from a safe place (aka local copy, barbican copy, etc.) Establishing a safe place outside Barbican has its drawbacks, e.g. a user's cert is compromised and he rather wants failover, etc. to fail then run any longer with the compromised cert -- So and that is a question back to Barbican. Can the "normal" delete just be a flag, e.g. deleted but still preserves the certificate and LBaaS can decide if they throw an error or utilize the deleted cert. And then we have an "rm -f" which nukes it and has side effects... German -----Original Message----- From: Doug Wiegley [mailto:do...@a10networks.com] Sent: Wednesday, June 11, 2014 10:57 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit There are other fundamental things about secrets, like relying on their presence, and not encouraging a proliferation of a dozen mini-secret-stores everywhere to get around that fact, which makes it less secret. Have you considered a ³force² delete flag, required if some service is using the secret, sort of ³rm² vs ³rm -f², to avoid the obvious foot-shooting use cases, but still allowing the user to nuke it if necessary? Thanks, Doug On 6/11/14, 11:43 AM, "Clark, Robert Graham" <robert.cl...@hp.com> wrote: >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 _______________________________________________ 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