Hi,
Please note as commented also by other XaaS services that managing SSL
certificates is not a sole LBaaS challenge.
This calls for either an OpenStack wide service or at least a Neutron wide
service to implement such use cases.
So it here are the options as far as I have seen so far.
1. Barbican as a central service to store and retrieve SSL certificates.
I think the Certificates generation is currently a lower priority requirement
2. Using Heat as a centralized service
3. Implementing such service in Neutron
4. LBaaS private implementation
BTW, on all the options above, Barbican can optionally be used to store the
certificates or the private part of the certificates.
I think that we either follow option 3 if SSL management is only a Neutron
requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition project to an
OpenStack wide solution (1 or 2).
Option 1 or 2 might be the ultimate goal.
Regards,
-Sam.
From: Clark, Robert Graham [mailto:robert.cl...@hp.com]
Sent: Thursday, May 08, 2014 12:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
implementation for LBaaS and VPN
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-container)
-Rob
From: Carlos Garza [mailto:carlos.ga...@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
<samu...@radware.com<mailto:samu...@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.w...@rackspace.com<http://RACKSPACE.COM>]
Sent: Thursday, May 01, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage questions);
os.v...@gmail.com<mailto:os.v...@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
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<mailto:samu...@radware.com>]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage questions);
os.v...@gmail.com<mailto: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<mailto: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
