Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
Hello folks, Barbican would like to assist in managing the workflow between a CA, crypto plugins and event subscribers to order, generate and securely store SSL certificate information, as per this blueprint: https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates Note however that the 'event subscribers' above would probably be specific to the openstack deployment and run outside of the Barbican service. So for Rackspace, these subscribers might be issuing tickets to our support folks, to then install the SSL certificates where they need to go. Thanks, John From: Eichberger, German [german.eichber...@hp.com] Sent: Thursday, May 08, 2014 3:12 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 Carlos, +1 My impression of barbican is that they indeed see themselves as sending updates to the LBs/VPN/X – but I am not too excited about that. Any marginally sophisticated user wants to control when we burst out new certificates so they can tie that to their maintenance window (in case client certs need to be updated). German From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Thursday, May 08, 2014 11:54 AM 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 8, 2014, at 1:41 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi, Some of our users are not that organized and certificate expirations seem to sneak up on them. So they are looking for a single place where they can “manage” their certificates. I am not sure if splitting storage between Barbican and Neutron will allow that. I am also wondering if Barbican is aspiring to become that central place… Ok but in our implementation we may decide to duplicate the X509s in our database so that we can search and do searches on them with out going over a separate API service. So we don't mind storing them in both locations. We just worry about case were people update their (x509,priv_key) via barbican but existing loadbalancers in neutron would then be unaware of the new updated cert. This would seem to imply that barbican would need to trigger an update on neutron/lbaas. :( German From: Carlos Garza [mailto:carlos.ga...@rackspace.comhttp://rackspace.com] Sent: Thursday, May 08, 2014 9:54 AM 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 8, 2014, at 5:19 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com 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. Is your statement equivalent to On all the options above, Babican can optionally be used to store the (X509,private_key) or just the private_key. If thats what you mean then we are on the same page. private part of a certificate is not a valid statement for me since x509 certs don't contain private parts. I'm advocating the latter where barbican stores the key only and we store the X509 on our own database. 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.comhttp://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
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-c ontainer) -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.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.v...@gmail.com 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 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:samu...@radware.com samu...@radware.com] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); mailto:os.v...@gmail.com 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-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.v...@gmail.com 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
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
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.commailto: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.comhttp://RACKSPACE.COM] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions); os.v...@gmail.commailto: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.commailto:samu...@radware.com] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); os.v...@gmail.commailto: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
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
My understanding is that option 1. Is already moving at pace it might just need a little finessing to ensure that it meets everyone's requirements. -Rob From: Samuel Bercovici [mailto:samu...@radware.com] Sent: 08 May 2014 11:20 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN 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-c ontainer) -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.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.v...@gmail.com 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 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:samu...@radware.com samu...@radware.com] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); mailto:os.v...@gmail.com os.v...@gmail.com Subject: Re: [openstack-dev] [Neutron
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
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
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
On May 8, 2014, at 5:19 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com 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. Is your statement equivalent to On all the options above, Babican can optionally be used to store the (X509,private_key) or just the private_key. If thats what you mean then we are on the same page. private part of a certificate is not a valid statement for me since x509 certs don't contain private parts. I'm advocating the latter where barbican stores the key only and we store the X509 on our own database. 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.comhttp://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.commailto: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.comhttp://RACKSPACE.COM] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions);os.v...@gmail.commailto: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.commailto:samu...@radware.com] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); os.v...@gmail.commailto:os.v...@gmail.com Subject: Re: [openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
Hi, Some of our users are not that organized and certificate expirations seem to sneak up on them. So they are looking for a single place where they can manage their certificates. I am not sure if splitting storage between Barbican and Neutron will allow that. I am also wondering if Barbican is aspiring to become that central place... German From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Thursday, May 08, 2014 9:54 AM 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 8, 2014, at 5:19 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com 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. Is your statement equivalent to On all the options above, Babican can optionally be used to store the (X509,private_key) or just the private_key. If thats what you mean then we are on the same page. private part of a certificate is not a valid statement for me since x509 certs don't contain private parts. I'm advocating the latter where barbican stores the key only and we store the X509 on our own database. 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.comhttp://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.commailto: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.comhttp://RACKSPACE.COM] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions);os.v...@gmail.commailto: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
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
Carlos, +1 My impression of barbican is that they indeed see themselves as sending updates to the LBs/VPN/X - but I am not too excited about that. Any marginally sophisticated user wants to control when we burst out new certificates so they can tie that to their maintenance window (in case client certs need to be updated). German From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Thursday, May 08, 2014 11:54 AM 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 8, 2014, at 1:41 PM, Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com wrote: Hi, Some of our users are not that organized and certificate expirations seem to sneak up on them. So they are looking for a single place where they can manage their certificates. I am not sure if splitting storage between Barbican and Neutron will allow that. I am also wondering if Barbican is aspiring to become that central place... Ok but in our implementation we may decide to duplicate the X509s in our database so that we can search and do searches on them with out going over a separate API service. So we don't mind storing them in both locations. We just worry about case were people update their (x509,priv_key) via barbican but existing loadbalancers in neutron would then be unaware of the new updated cert. This would seem to imply that barbican would need to trigger an update on neutron/lbaas. :( German From: Carlos Garza [mailto:carlos.ga...@rackspace.comhttp://rackspace.com] Sent: Thursday, May 08, 2014 9:54 AM 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 8, 2014, at 5:19 AM, Samuel Bercovici samu...@radware.commailto:samu...@radware.com 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. Is your statement equivalent to On all the options above, Babican can optionally be used to store the (X509,private_key) or just the private_key. If thats what you mean then we are on the same page. private part of a certificate is not a valid statement for me since x509 certs don't contain private parts. I'm advocating the latter where barbican stores the key only and we store the X509 on our own database. 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.comhttp://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.commailto: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
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
+1 to implement a modular framework where user can choose whether to use barbican or sqldb On Fri, May 2, 2014 at 4:28 AM, John Wood john.w...@rackspace.com wrote: 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] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); 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 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
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
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. -Sam. From: John Wood [mailto:john.w...@rackspace.com] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions); 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] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); os.v...@gmail.commailto: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
Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN
I thought the requirement was from the need to ensure the backend was secure. IE people would throw a fit if they find out your storing keys in sqllite or MySQL. Wasn't the purpose to find A Secure repository? On May 7, 2014, at 10:38 AM, Zang MingJie zealot0...@gmail.com wrote: +1 to implement a modular framework where user can choose whether to use barbican or sqldb On Fri, May 2, 2014 at 4:28 AM, John Wood john.w...@rackspace.com wrote: 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] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); 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
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.commailto: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.comhttp://RACKSPACE.COM] Sent: Thursday, May 01, 2014 11:28 PM To: OpenStack Development Mailing List (not for usage questions); os.v...@gmail.commailto: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.commailto:samu...@radware.com] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); os.v...@gmail.commailto: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
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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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] Sent: Thursday, May 01, 2014 12:50 PM To: OpenStack Development Mailing List (not for usage questions); 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
