Open Stack

Hi Doug,


Barbican does guarantee the integrity and availability of the secret,
unless the owner of the secret deletes it from Barbican.  We’re not
encouraging that you store a shadow-copy of the secret either.  This was
proposed by the LBaaS team as a possible workaround for your use case.
Our recommendation was that there are two options for dealing with Secrets
being deleted from under you:

If you want to control the lifecycle of the secret so that you can prevent
the user from deleting the secret, then the secret should be owned by
LBaaS, not by the user.  You can achieve this by asking the user to upload
the secret via LBaaS api, and then use Barbican on the back end to store
the secret under the LBaaS tenant.

If you want the user to own and manage their secret in Barbican, then you
have to deal with the situation where the user deletes a secret and it is
no longer available to LBaaS.  This is a situation you would have to deal
with even with a reference-counting and force-deleting Barbican, so I
don’t think you really gain anything from all the complexity you’re
proposing to add to Barbican.

-Douglas M.



On 6/11/14, 12:57 PM, "Doug Wiegley" <dougw at a10networks.com> wrote:

>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
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5660 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140611/4505d632/attachment.bin>