[openstack-dev] [Neutron][LBaaS] TLS support RST document on Gerrit

Clark, Robert Graham robert.clark at hp.com
Wed Jun 11 17:43:11 UTC 2014


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140611/e317973a/attachment.bin>


More information about the OpenStack-dev mailing list