Open Stack

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.clark at 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.garza at 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 <SamuelB at 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 at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev