[openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Vijay.Venkatachalam at citrix.com
Wed Nov 20 06:05:47 UTC 2013
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.
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
Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
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.
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!
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev