Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi, I've updated the wiki page Please see and comment https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL Thanks, Evg -Original Message- From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Wednesday, November 20, 2013 4:17 PM To: Samuel Bercovici; OpenStack Development Mailing List (not for usage questions); stephen.g...@guardian.co.uk Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Yes. The following can be added 1. Certificate Chain as you already observed 2. Backend certificates for trust, basically CA certs. These certificates will be used by loadbalancer to validate the certificate presented by the backend services. Thanks, Vijay V. -Original Message- From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Wednesday, November 20, 2013 5:40 PM To: OpenStack Development Mailing List (not for usage questions); stephen.g...@guardian.co.uk; Vijay Venkatachalam Subject: RE: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up HI, Besides a forward looking model do you see other differences? -Sam. -Original Message- From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Wednesday, November 20, 2013 1:22 PM To: stephen.g...@guardian.co.uk; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up -Original Message- From: Stephen Gran [mailto:stephen.g...@guardian.co.uk] Sent: Wednesday, November 20, 2013 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi, On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote: Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n YTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? You could reuse the same certificate for multiple loadbalancer VIPs. This is a fairly common pattern - we have a dev wildcard cert that is self- signed, and is used for lots of VIPs. If certificates can be totally independent and can be reused, it will be awesome. But even otherwise, certificate connected to VIP is just better modeling and provides an easier migration path towards an independent certificate resource. When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. It probably doesn't need anything that complicated, does it? Cheers, -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e- mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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 ___ 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] SSL Termination write-up
On 19/11/13 16:33, Clint Byrum wrote: Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 -0800: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I don't see why it does. Nothing in openstack needs to trust user-uploaded certs. Just storing them as independent certificate objects that can be referenced by N VIPs makes sense to me. If the backend is SSL, I would think you could do one of: a) upload client certs b) upload CA that has signed backend certs c) opt to disable cert checking for backends With the default being c). Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. -Sam. From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Wednesday, November 20, 2013 8:06 AM To: Eugene Nikanorov Cc: Samuel Bercovici; Avishay Balderman; openstack-dev@lists.openstack.org Subject: RE: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi Eugene, The proposal is simple, create a separate resource called certificate (which will also be handled by Neutron+LBaaS plugin) rather than having them in the VIP. It will maintain the original thought of security, the certificate confidential parameters will be transient and the certificate will be directly sent to the device/driver and will not be stored. This is done by having VIP as a property in certificate. Thanks, Vijay V. From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Wednesday, November 20, 2013 1:59 AM To: Vijay Venkatachalam Cc: Samuel Bercovici; Avishay Balderman; openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi Vijay, Thanks for working on this. As was discussed at the summit, immediate solution seems to be passing certificates via transient fields in Vip object, which will avoid the need for certificate management (incl. storing them). If certificate management is concerned then I agree that it needs to be a separate specialized service. My thought was to have independent certificate resource with VIP uuid as one of the properties. VIP is already created and will help to identify the driver/device. The VIP property can be depreciated in the long term. I think it's a little bit forward looking at this moment, also I think that certificates are not specific for load balancing. Transient fields could help here too: client could pass certificate Id and driver of corresponding device will communicate with external service fetching corresponding certificate. Thanks, Eugene. On Tue, Nov 19, 2013 at 5:48 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I would expect the certificates to become an independent resource in future thereby causing backward compatibility issues. Any ideas how to achieve this? My thought was to have independent certificate resource with VIP uuid as one of the properties. VIP is already created and will help to identify the driver/device. The VIP property can be depreciated in the long term. Thanks, Vijay V. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi Stephen, When this was discussed in the past, customer were not happy about storing their SSL certificates in the OpenStack database as plain fields as they felt that this is not secured enough. Do you say, that you are OK with storing SSL certificates in the OpenStack database? -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Wednesday, November 20, 2013 10:15 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up On 19/11/13 16:33, Clint Byrum wrote: Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 -0800: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYT vMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I don't see why it does. Nothing in openstack needs to trust user-uploaded certs. Just storing them as independent certificate objects that can be referenced by N VIPs makes sense to me. If the backend is SSL, I would think you could do one of: a) upload client certs b) upload CA that has signed backend certs c) opt to disable cert checking for backends With the default being c). Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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] SSL Termination write-up
Hi, Yes, definitely yes. It's just a bootstrap problem - you can't both have a reliable, resilient loadbalancer that can be respawned, and not store all the data necessary to respawn it. I agree there are privacy concerns, just as there are with any hoster. But if you don't trust your hoster with your SSL certs, you probably shouldn't host any content that matters with them. Cheers, On Wed, 2013-11-20 at 08:43 +, Samuel Bercovici wrote: Hi Stephen, When this was discussed in the past, customer were not happy about storing their SSL certificates in the OpenStack database as plain fields as they felt that this is not secured enough. Do you say, that you are OK with storing SSL certificates in the OpenStack database? -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Wednesday, November 20, 2013 10:15 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up On 19/11/13 16:33, Clint Byrum wrote: Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 -0800: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYT vMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I don't see why it does. Nothing in openstack needs to trust user-uploaded certs. Just storing them as independent certificate objects that can be referenced by N VIPs makes sense to me. If the backend is SSL, I would think you could do one of: a) upload client certs b) upload CA that has signed backend certs c) opt to disable cert checking for backends With the default being c). Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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 -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi, On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote: Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? You could reuse the same certificate for multiple loadbalancer VIPs. This is a fairly common pattern - we have a dev wildcard cert that is self-signed, and is used for lots of VIPs. When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. It probably doesn't need anything that complicated, does it? Cheers, -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi, Replies Inline! -Original Message- From: Stephen Gran [mailto:stephen.g...@guardian.co.uk] Sent: Wednesday, November 20, 2013 2:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi, Yes, definitely yes. It's just a bootstrap problem - you can't both have a reliable, resilient loadbalancer that can be respawned, and not store all the data necessary to respawn it. Not necessarily. Devices can be in HA or clustering mode. Any configuration that is sent to one device will be synced with other paired devices securely and would also failover at the right time. I agree there are privacy concerns, just as there are with any hoster. But if you don't trust your hoster with your SSL certs, you probably shouldn't host any content that matters with them. I am no way expert in this area, but I think it is not a question of trust but it is a fear that a security loophole in the controller could be exploited to read the certificates. I don't know of any concerns though. Cheers, On Wed, 2013-11-20 at 08:43 +, Samuel Bercovici wrote: Hi Stephen, When this was discussed in the past, customer were not happy about storing their SSL certificates in the OpenStack database as plain fields as they felt that this is not secured enough. Do you say, that you are OK with storing SSL certificates in the OpenStack database? -Sam. -Original Message- From: Stephen Gran [mailto:stephen.g...@theguardian.com] Sent: Wednesday, November 20, 2013 10:15 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up On 19/11/13 16:33, Clint Byrum wrote: Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 - 0800: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n YT vMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I don't see why it does. Nothing in openstack needs to trust user-uploaded certs. Just storing them as independent certificate objects that can be referenced by N VIPs makes sense to me. If the backend is SSL, I would think you could do one of: a) upload client certs b) upload CA that has signed backend certs c) opt to disable cert checking for backends With the default being c). Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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 -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
-Original Message- From: Stephen Gran [mailto:stephen.g...@guardian.co.uk] Sent: Wednesday, November 20, 2013 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi, On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote: Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n YTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? You could reuse the same certificate for multiple loadbalancer VIPs. This is a fairly common pattern - we have a dev wildcard cert that is self- signed, and is used for lots of VIPs. If certificates can be totally independent and can be reused, it will be awesome. But even otherwise, certificate connected to VIP is just better modeling and provides an easier migration path towards an independent certificate resource. When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. It probably doesn't need anything that complicated, does it? Cheers, -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e- mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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] SSL Termination write-up
HI, Besides a forward looking model do you see other differences? -Sam. -Original Message- From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Wednesday, November 20, 2013 1:22 PM To: stephen.g...@guardian.co.uk; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up -Original Message- From: Stephen Gran [mailto:stephen.g...@guardian.co.uk] Sent: Wednesday, November 20, 2013 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi, On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote: Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n YTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? You could reuse the same certificate for multiple loadbalancer VIPs. This is a fairly common pattern - we have a dev wildcard cert that is self- signed, and is used for lots of VIPs. If certificates can be totally independent and can be reused, it will be awesome. But even otherwise, certificate connected to VIP is just better modeling and provides an easier migration path towards an independent certificate resource. When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. It probably doesn't need anything that complicated, does it? Cheers, -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e- mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Yes. The following can be added 1. Certificate Chain as you already observed 2. Backend certificates for trust, basically CA certs. These certificates will be used by loadbalancer to validate the certificate presented by the backend services. Thanks, Vijay V. -Original Message- From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Wednesday, November 20, 2013 5:40 PM To: OpenStack Development Mailing List (not for usage questions); stephen.g...@guardian.co.uk; Vijay Venkatachalam Subject: RE: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up HI, Besides a forward looking model do you see other differences? -Sam. -Original Message- From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] Sent: Wednesday, November 20, 2013 1:22 PM To: stephen.g...@guardian.co.uk; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up -Original Message- From: Stephen Gran [mailto:stephen.g...@guardian.co.uk] Sent: Wednesday, November 20, 2013 3:01 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up Hi, On Wed, 2013-11-20 at 08:24 +, Samuel Bercovici wrote: Hi, Evgeny has outlined the wiki for the proposed change at: https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line with what was discussed during the summit. The https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2n YTvMkMJ_inbo/edit discuss in addition Certificate Chains. What would be the benefit of having a certificate that must be connected to VIP vs. embedding it in the VIP? You could reuse the same certificate for multiple loadbalancer VIPs. This is a fairly common pattern - we have a dev wildcard cert that is self- signed, and is used for lots of VIPs. If certificates can be totally independent and can be reused, it will be awesome. But even otherwise, certificate connected to VIP is just better modeling and provides an easier migration path towards an independent certificate resource. When we get a system that can store certificates (ex: Barbican), we will add support to it in the LBaaS model. It probably doesn't need anything that complicated, does it? Cheers, -- Stephen Gran Senior Systems Integrator - The Guardian Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e- mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I would expect the certificates to become an independent resource in future thereby causing backward compatibility issues. Any ideas how to achieve this? My thought was to have independent certificate resource with VIP uuid as one of the properties. VIP is already created and will help to identify the driver/device. The VIP property can be depreciated in the long term. Thanks, Vijay V. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 -0800: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I would expect the certificates to become an independent resource in future thereby causing backward compatibility issues. Perhaps Barbican can be leveraged for this, it seems that it was specifically designed for the use case. Quoting from their README: Design Goals 1. Provide a central secret-store capable of distributing secret / keying material to all types of deployments including ephemeral Cloud instances. 2. Support reasonable compliance regimes through reporting and auditability. 3. Application adoption costs should be minimal or non-existent. 4. Build a community and ecosystem by being open-source and extensible. 5. Improve security through sane defaults and centralized management of policies for all secrets. 6. Out of band communication mechanism to notify and protect sensitive assets. https://github.com/stackforge/barbican ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/11/13 16:33, Clint Byrum wrote: Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43 -0800: Hi Sam, Eugene, Avishay, etal, Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments! https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit Would like comments/discussion especially on the following note: SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don't store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller. I would expect the certificates to become an independent resource in future thereby causing backward compatibility issues. Perhaps Barbican can be leveraged for this, it seems that it was Indeed, the planned Libra solution for this is to use Barbican. We did some investigation into this when Barbican was a very new project but unfortunately it wasn't quite ready at the time. We will be looking into this again in the coming months. Kind Regards - -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSjGpOAAoJEJfFW8uxApB2VQQH/RdqegsTw5TsqIeARRwv4XPP 9VgpbuPuUmENJ2zBa9LPM1+ytY61LQRXUpLtYMxN3iefndgACvEgJ/hfVeiu7F6T YDQyu3K6XtSJ4E1bizJQyyU0Q1bXzsb/3J/Nh3E5RRZ/vQCRAvnihiehDr8R002e YdzOIorMP45kmHg77CCq9wKEffUDGzr/vqa+5xERSOCkt3TvB7T8BW+f9DipVH/G 9pbTvkqWsHB0ppytgTM7rv1P7ltAvSDPdC6ALh7q/oQU7QAMr1XxZSEbJCYzXLqb WAt1QYC0EddxKArQmPA5LmMoOW02c76sJqKHeZbrZEERB4nxbZMPvjAKf4F+8Mw= =uJGy -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
