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