[openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)
SamuelB at Radware.com
Thu Dec 5 19:14:12 UTC 2013
Evgeny will update the WIKI accordingly.
We will add a flag in the SSL Certificate to allow specifying that the private key can't be persisted. And in this case, the private key could be passed when associating the cert_id with the VIP.
From: Nachi Ueno [mailto:nachi at ntti3.com]
Sent: Thursday, December 05, 2013 8:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for certificate as first-class citizen - SSL Termination (Revised)
OK, It looks like we get consensus on
separate resource" way.
2013/12/5 Eugene Nikanorov <enikanorov at mirantis.com>:
> My vote is for separate resource (e.g. 'New Model'). Also I'd like to
> see certificate handling as a separate extension/db mixing(in fact,
> driver) similar to service_type extension.
> On Thu, Dec 5, 2013 at 2:13 PM, Stephen Gran
> <stephen.gran at theguardian.com>
>> Right, sorry, I see that wasn't clear - I blame lack of coffee :)
>> I would prefer the "Revised New Model". I much prefer the ability to
>> restore a loadbalancer from config in the event of node failure, and
>> the ability to do basic sharing of certificates between VIPs.
>> I think that a longer term plan may involve putting the certificates
>> in a smarter system if we decide we want to do things like evaluate
>> trust models, but just storing them locally for now will do most of
>> what I think people want to do with SSL termination.
>> On 05/12/13 09:57, Samuel Bercovici wrote:
>>> Hi Stephen,
>>> To make sure I understand, which model is fine "Basic/Simple" or "New".
>>> -----Original Message-----
>>> From: Stephen Gran [mailto:stephen.gran at theguardian.com]
>>> Sent: Thursday, December 05, 2013 8:22 AM
>>> To: openstack-dev at lists.openstack.org
>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] Vote required for
>>> certificate as first-class citizen - SSL Termination (Revised)
>>> I would be happy with this model. Yes, longer term it might be nice
>>> to have an independent certificate store so that when you need to be
>>> able to validate ssl you can, but this is a good intermediate step.
>>> On 02/12/13 09:16, Vijay Venkatachalam wrote:
>>>> LBaaS enthusiasts: Your vote on the revised model for SSL Termination?
>>>> Here is a comparison between the original and revised model for SSL
>>>> Original Basic Model that was proposed in summit
>>>> * Certificate parameters introduced as part of VIP resource.
>>>> * This model is for basic config and there will be a model
>>>> introduced in future for detailed use case.
>>>> * Each certificate is created for one and only one VIP.
>>>> * Certificate params not stored in DB and sent directly to loadbalancer.
>>>> * In case of failures, there is no way to restart the operation
>>>> from details stored in DB.
>>>> Revised New Model
>>>> * Certificate parameters will be part of an independent certificate
>>>> resource. A first-class citizen handled by LBaaS plugin.
>>>> * It is a forwarding looking model and aligns with AWS for
>>>> uploading server certificates.
>>>> * A certificate can be reused in many VIPs.
>>>> * Certificate params stored in DB.
>>>> * In case of failures, parameters stored in DB will be used to
>>>> restore the system.
>>>> A more detailed comparison can be viewed in the following link
>> Stephen Gran
>> Senior Systems Integrator - theguardian.com Please consider the
>> environment before printing this email.
>> Visit theguardian.com
>> On your mobile, download the Guardian iPhone app theguardian.com/iphone
>> and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to
>> the Guardian and Observer - choose the papers you want and get full
>> digital access.
>> Visit subscribe.theguardian.com
>> This e-mail and all attachments are confidential and may also be
>> privileged. If you are not the named recipient, please notify the
>> sender and delete the e-mail and all attachments immediately.
>> Do not disclose the contents to another person. You may not use the
>> information for any purpose, or store, or copy, it in any way.
>> Guardian News & Media Limited is not liable for any computer viruses
>> or other material transmitted with or as part of this e-mail. You
>> should employ virus checking software.
>> Guardian News & Media Limited
>> A member of Guardian Media Group plc
>> Registered Office
>> PO Box 68164
>> Kings Place
>> 90 York Way
>> N1P 2AP
>> Registered in England Number 908396
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev