[openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

Clark, Robert Graham robert.clark at hp.com
Thu May 8 09:42:41 UTC 2014


The certificate management that LBaaS requires might be slightly
different to the normal flow of things in OpenStack services, after all
you are talking about externally provided certificates and private keys.

 

There's already a standard for a nice way to bundle those two elements
together, it's described in PKCS#12 and you've likely come across it in
the form of '.pfx' files. I'd suggest that perhaps it would make sense
for LBaaS to store pfx files in the LBaaS DB and store the key for the
pfx files in Barbican. You could probably store them together in
Barbican, using containers if you really wanted to
(https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-c
ontainer) 

 

-Rob

 

From: Carlos Garza [mailto:carlos.garza at rackspace.com] 
Sent: 08 May 2014 04:30
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN

 

 

On May 7, 2014, at 10:53 AM, Samuel Bercovici <SamuelB at Radware.com
<mailto:SamuelB at Radware.com> > wrote:





Hi John,

 

If the user already has an SSL certificate that was acquired outside of
the barbican Ordering system, how can he store it securely in Barbican
as a SSL Certificate?

The Container stored this information in a very generic way, I think
that there should be an API that formalizes a specific way in which SSL
certificates can be stored and read back as SSL Certificates and not as
loosely coupled container structure.

This such API should have RBAC that allows getting back only the public
part of an SSL certificate vs. allowing to get back all the details of
the SSL certificate.

 

    Why the need for that complexity? The X509s are public by nature and
don't need to be stored in Barbican so there isn't really a private part
of the certificate. The actual private key itself is what needs to be
secured so I would advocate that the private key is what will be stored
in barbican. I also think we should also declare that the private key
need not be an RSA key as x509 supports other asymmetric encryption
types so storing as a generic blob in barbican is probably a good idea.

 





 

 

 

-Sam.

 

 

 

From: John Wood [mailto:john.wood@ <http://RACKSPACE.COM> RACKSPACE.COM]

Sent: Thursday, May 01, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage questions);
<mailto:os.vbvs at gmail.com> os.vbvs at gmail.com
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN

 

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>
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 [ <mailto:SamuelB at Radware.com>
SamuelB at Radware.com]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage questions);
<mailto:os.vbvs at gmail.com> 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-Inte
rface>
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Inter
face

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> 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://review.openstack.org/#/c/74031/   (
<https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL>
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)

 

 <https://review.openstack.org/#/c/58897/>
https://review.openstack.org/#/c/58897/   (
<https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn>
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
 <mailto:OpenStack-dev at lists.openstack.org>
OpenStack-dev at lists.openstack.org
 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140508/388049fc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140508/388049fc/attachment.bin>


More information about the OpenStack-dev mailing list