Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up

2013-11-26 Thread Evgeny Fedoruk
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

2013-11-20 Thread Stephen Gran

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

2013-11-20 Thread Samuel Bercovici
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

2013-11-20 Thread Samuel Bercovici
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

2013-11-20 Thread Stephen Gran
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

2013-11-20 Thread Stephen Gran
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

2013-11-20 Thread Vijay Venkatachalam
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

2013-11-20 Thread Vijay Venkatachalam


 -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

2013-11-20 Thread Samuel Bercovici
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

2013-11-20 Thread Vijay Venkatachalam
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


Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up

2013-11-19 Thread Clint Byrum
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

2013-11-19 Thread Eugene Nikanorov
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.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

2013-11-19 Thread Andrew Hutchings
-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