+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.w...@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 [samu...@radware.com] > Sent: Thursday, May 01, 2014 12:50 PM > To: OpenStack Development Mailing List (not for usage questions); > os.v...@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.v...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
