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.venkatacha...@citrix.com]
Sent: Wednesday, November 20, 2013 8:06 AM
To: Eugene Nikanorov
Cc: Samuel Bercovici; Avishay Balderman; openstack-dev@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:enikano...@mirantis.com]
Sent: Wednesday, November 20, 2013 1:59 AM
To: Vijay Venkatachalam
Cc: Samuel Bercovici; Avishay Balderman; 
openstack-dev@lists.openstack.org<mailto:openstack-dev@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.venkatacha...@citrix.com<mailto:vijay.venkatacha...@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.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to