Open Stack

Hi,

Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit.
The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit discuss in addition Certificate Chains.

What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP?
When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model.

-Sam.



From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam at citrix.com]
Sent: Wednesday, November 20, 2013 8:06 AM
To: Eugene Nikanorov
Cc: Samuel Bercovici; Avishay Balderman; openstack-dev at lists.openstack.org
Subject: RE: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up

Hi Eugene,

                The proposal is simple, create a separate resource called certificate (which will also be handled by Neutron+LBaaS plugin) rather than having them in the VIP. It will maintain the original thought of security, the certificate confidential parameters will  be transient and the certificate will be directly sent to the device/driver and will not be stored. This is done by having VIP as a property in certificate.

Thanks,
Vijay V.

From: Eugene Nikanorov [mailto:enikanorov at mirantis.com]
Sent: Wednesday, November 20, 2013 1:59 AM
To: Vijay Venkatachalam
Cc: Samuel Bercovici; Avishay Balderman; openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up

Hi Vijay,

Thanks for working on this. As was discussed at the summit, immediate solution seems to be passing certificates via transient fields in Vip object, which will avoid the need for certificate management (incl. storing them).
If certificate management is concerned then I agree that it needs to be a separate specialized service.

> My thought was to have independent certificate resource with VIP uuid as one of the properties. VIP is already created and
> will help to identify the driver/device. The VIP property can be depreciated in the long term.
I think it's a little bit forward looking at this moment, also I think that certificates are not specific for load balancing.
Transient fields could help here too: client could pass certificate Id and driver of corresponding device will communicate with external service fetching corresponding certificate.

Thanks,
Eugene.

On Tue, Nov 19, 2013 at 5:48 PM, Vijay Venkatachalam <Vijay.Venkatachalam at citrix.com<mailto:Vijay.Venkatachalam at citrix.com>> wrote:
Hi Sam, Eugene, & Avishay, etal,

                Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments!

https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit

Would like comments/discussion especially on the following note:

SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller.

I would expect the certificates to become an independent resource in future thereby causing backward compatibility issues.

Any ideas how to achieve this?

My thought was to have independent certificate resource with VIP uuid as one of the properties. VIP is already created and will help to identify the driver/device. The VIP property can be depreciated in the long term.
Thanks,
Vijay V.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/a421fe67/attachment.html>