[openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

Carlos Garza carlos.garza at rackspace.com
Thu May 8 03:23:52 UTC 2014


    I thought the requirement was from the need to ensure the backend was secure. IE people would throw a fit if they find out your storing keys in sqllite or MySQL. Wasn't the purpose to find "A Secure repository"?

On May 7, 2014, at 10:38 AM, Zang MingJie <zealot0630 at gmail.com> wrote:

> +1 to implement a modular framework where user can choose whether to
> use barbican or sqldb
> 
> On Fri, May 2, 2014 at 4:28 AM, John Wood <john.wood at rackspace.com> wrote:
>> Hello Samuel,
>> 
>> Just noting that the link below shows current-state Barbican. We are in the
>> process of designing SSL certificate support for Barbican via blueprints
>> such as this one:
>> https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates
>> We intend to discuss this feature in Atlanta to enable coding in earnest for
>> Juno.
>> 
>> The Container resource is intended to capture/store the final certificate
>> details.
>> 
>> Thanks,
>> John
>> 
>> 
>> ________________________________
>> From: Samuel Bercovici [SamuelB at Radware.com]
>> Sent: Thursday, May 01, 2014 12:50 PM
>> To: OpenStack Development Mailing List (not for usage questions);
>> os.vbvs at gmail.com
>> Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
>> implementation for LBaaS and VPN
>> 
>> Hi Vijay,
>> 
>> 
>> 
>> I have looked at the Barbican APIs –
>> https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
>> 
>> I was no able to see a “native” API that will accept an SSL certificate
>> (private key, public key, CSR, etc.) and will store it.
>> 
>> We can either store the whole certificate as a single file as a secret or
>> use a container and store all the certificate parts as secrets.
>> 
>> 
>> 
>> I think that having LBaaS reference Certificates as IDs using some service
>> is the right way to go so this might be achived by either:
>> 
>> 1.       Adding to Barbican and API to store / generate certificates
>> 
>> 2.       Create a new “module” that might start by being hosted in neutron
>> or keystone that will allow to manage certificates and will use Barbican
>> behind the scenes to store them.
>> 
>> 3.       Decide on a container structure to use in Babican but implement the
>> way to access and arrange it as a neutron library
>> 
>> 
>> 
>> Was any decision made on how to proceed?
>> 
>> 
>> 
>> Regards,
>> 
>>                -Sam.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Vijay B [mailto:os.vbvs at gmail.com]
>> Sent: Wednesday, April 30, 2014 3:24 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for
>> LBaaS and VPN
>> 
>> 
>> 
>> Hi,
>> 
>> 
>> 
>> It looks like there are areas of common effort in multiple efforts that are
>> proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in
>> neutron.
>> 
>> 
>> 
>> Two relevant efforts are listed below:
>> 
>> 
>> 
>> 
>> 
>> https://review.openstack.org/#/c/74031/
>> (https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)
>> 
>> 
>> 
>> https://review.openstack.org/#/c/58897/
>> (https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Both VPN and LBaaS will use SSL certificates and keys, and this makes it
>> better to implement SSL entities as first class citizens in the OS world.
>> So, three points need to be discussed here:
>> 
>> 
>> 
>> 1. The VPN SSL implementation above is putting the SSL cert content in a
>> mapping table, instead of maintaining certs separately and referencing them
>> using IDs. The LBaaS implementation stores certificates in a separate table,
>> but implements the necessary extensions and logic under LBaaS. We propose
>> that both these implementations move away from this and refer to SSL
>> entities using IDs, and that the SSL entities themselves are implemented as
>> their own resources, serviced either by a core plugin or a new SSL plugin
>> (assuming neutron; please also see point 3 below).
>> 
>> 
>> 
>> 2. The actual data store where the certs and keys are stored should be
>> configurable at least globally, such that the SSL plugin code will
>> singularly refer to that store alone when working with the SSL entities. The
>> data store candidates currently are Barbican and a sql db. Each should have
>> a separate backend driver, along with the required config values. If further
>> evaluation of Barbican shows that it fits all SSL needs, we should make it a
>> priority over a sqldb driver.
>> 
>> 
>> 
>> 3. Where should the primary entries for the SSL entities be stored? While
>> the actual certs themselves will reside on Barbican or SQLdb, the entities
>> themselves are currently being implemented in Neutron since they are being
>> used/referenced there. However, we feel that implementing them in keystone
>> would be most appropriate. We could also follow a federated model where a
>> subset of keys can reside on another service such as Neutron. We are fine
>> with starting an initial implementation in neutron, in a modular manner, and
>> move it later to keystone.
>> 
>> 
>> 
>> 
>> 
>> Please provide your inputs on this.
>> 
>> 
>> 
>> 
>> 
>> Thanks,
>> 
>> Regards,
>> 
>> Vijay
>> 
>> 
>> _______________________________________________
>> 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




More information about the OpenStack-dev mailing list