Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140501/d042d232/attachment.html>