Open Stack

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/20140429/7fca1fe6/attachment.html>