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:[email protected]]
Sent: Wednesday, November 20, 2013 1:59 AM
To: Vijay Venkatachalam
Cc: Samuel Bercovici; Avishay Balderman; [email protected]
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
<[email protected]<mailto:[email protected]>> 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.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
