On 05/08/2014 03:19 AM, Samuel Bercovici wrote: > 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.
It's really just private keys you need to be concerned about, not certificates themselves (which are really just a signed public key plus other public data like the subject, issuer, and validity). > > > > 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). I'd be concerned about implementing a separate service when this clearly falls into Barbican's target use-cases. We should be moving towards centralizing security related functionality like this instead of having multiple implementations of similar functionality. > > Option 1 or 2 might be the ultimate goal. I think 1 should be the ultimate goal. Barbican is designed for securely storing keys, which is exactly what you are trying to do. Thanks, -NGK > > > > 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev