Open Stack

+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
>