Open Stack

Hi,

The primary reason for the "simple" proposal is due to the difficult to reach consensus on how SSL certificates can be stored in OpenStack.
As there is currently no "trusted" storage in OpenStack, the "simple" proposal overcomes this by pushing the SSL certificates into the load balancers which are considered "trusted".
If there is an agreement that storing the SSL certificates and similar information in the OpenStack database is fine, than having the feature modeled with SSL certificates and SSL policies as 1st level citizens is preferable.

As Vijay mentioned, both options will support well the common use cases.

Hopefully, we can get other people to vote on this and drive a decision.

Regards,
	-Sam.


-----Original Message-----
From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam at citrix.com] 
Sent: Monday, December 02, 2013 11:16 AM
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)


LBaaS enthusiasts: Your vote on the revised model for SSL Termination?

Here is a comparison between the original and revised model for SSL Termination:

***************
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  https://docs.google.com/document/d/1fFHbg3beRtmlyiryHiXlpWpRo1oWj8FqVeZISh07iGs/edit?usp=sharing

Thanks,
Vijay V.


> -----Original Message-----
> From: Vijay Venkatachalam
> Sent: Friday, November 29, 2013 2:18 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Neutron][LBaaS] Vote required for 
> certificate as first level citizen - SSL Termination
> 
> 
> To summarize:
> Certificate will be a first level citizen which can be reused and For 
> certificate management nothing sophisticated is required.
> 
> Can you please Vote (+1, -1)?
> 
> We can move on if there is consensus around this.
> 
> > -----Original Message-----
> > From: Stephen Gran [mailto:stephen.gran at guardian.co.uk]
> > Sent: Wednesday, November 20, 2013 3:01 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination 
> > write-up
> >
> > Hi,
> >
> > On Wed, 2013-11-20 at 08:24 +0000, Samuel Bercovici wrote:
> > > 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/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n
> > YTvMkMJ_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?
> >
> > You could reuse the same certificate for multiple loadbalancer VIPs.
> > This is a fairly common pattern - we have a dev wildcard cert that 
> > is
> > self- signed, and is used for lots of VIPs.
> >
> > > When we get a system that can store certificates (ex: Barbican), 
> > > we will add support to it in the LBaaS model.
> >
> > It probably doesn't need anything that complicated, does it?
> >
> > Cheers,
> > --
> > Stephen Gran
> > Senior Systems Integrator - The Guardian
> >
> > 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
> > London
> > N1P 2AP
> >
> > Registered in England Number 908396
> >
> > --------------------------------------------------------------------
> > --
> > ----
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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