Open Stack

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.clark at 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.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 at RACKSPACE.COM
>     <http://RACKSPACE.COM>] 
>     *Sent:* Thursday, May 01, 2014 11:28 PM
>     *To:* OpenStack Development Mailing List (not for usage questions);
>     os.vbvs at gmail.com <mailto: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
> 
>     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
>     <mailto: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 <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>  
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>