Re: [New Feature FS] SSL Offload Support for Cloudstack
Thanks On Wed 15 Jan 2014 06:19:17 PM EST, Syed Ahmed wrote: Yes the work is complete. This is available via the API. I will resolve the ticket. Thanks, -Syed On Wed 15 Jan 2014 06:17:37 PM EST, Animesh Chaturvedi wrote: Syed I see the issue is not resolved and not tagged for 4.3. Is the work all complete. If so can you resolve the ticket and tag for fixVersion as 4.3 Animesh -Original Message- From: Syed Ahmed [mailto:sah...@cloudops.com] Sent: Tuesday, October 08, 2013 11:14 AM To: dev@cloudstack.apache.org Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc Bisaillon Subject: [New Feature FS] SSL Offload Support for Cloudstack Hi, I have been working on adding SSL offload functionality to cloudstack and make it work for Netscaler. I have an initial design documented at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support and I would really love your feedback. The bug for this is https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . Thanks, -Syed
RE: [New Feature FS] SSL Offload Support for Cloudstack
Ok no problem I just resolve the ticket and tagged for 4.3 -Original Message- From: Syed Ahmed [mailto:sah...@cloudops.com] Sent: Wednesday, January 15, 2014 3:19 PM To: dev@cloudstack.apache.org Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc Bisaillon; Animesh Chaturvedi Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack Yes the work is complete. This is available via the API. I will resolve the ticket. Thanks, -Syed On Wed 15 Jan 2014 06:17:37 PM EST, Animesh Chaturvedi wrote: > Syed > > I see the issue is not resolved and not tagged for 4.3. Is the work > all complete. If so can you resolve the ticket and tag for fixVersion > as 4.3 > > Animesh > > -Original Message- > From: Syed Ahmed [mailto:sah...@cloudops.com] > Sent: Tuesday, October 08, 2013 11:14 AM > To: dev@cloudstack.apache.org > Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc > Bisaillon > Subject: [New Feature FS] SSL Offload Support for Cloudstack > > Hi, > > I have been working on adding SSL offload functionality to cloudstack > and make it work for Netscaler. I have an initial design documented at > https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+ > Support and I would really love your feedback. The bug for this is > https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . > > Thanks, > -Syed > >
Re: [New Feature FS] SSL Offload Support for Cloudstack
Yes the work is complete. This is available via the API. I will resolve the ticket. Thanks, -Syed On Wed 15 Jan 2014 06:17:37 PM EST, Animesh Chaturvedi wrote: Syed I see the issue is not resolved and not tagged for 4.3. Is the work all complete. If so can you resolve the ticket and tag for fixVersion as 4.3 Animesh -Original Message- From: Syed Ahmed [mailto:sah...@cloudops.com] Sent: Tuesday, October 08, 2013 11:14 AM To: dev@cloudstack.apache.org Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc Bisaillon Subject: [New Feature FS] SSL Offload Support for Cloudstack Hi, I have been working on adding SSL offload functionality to cloudstack and make it work for Netscaler. I have an initial design documented at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support and I would really love your feedback. The bug for this is https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . Thanks, -Syed
RE: [New Feature FS] SSL Offload Support for Cloudstack
Syed I see the issue is not resolved and not tagged for 4.3. Is the work all complete. If so can you resolve the ticket and tag for fixVersion as 4.3 Animesh -Original Message- From: Syed Ahmed [mailto:sah...@cloudops.com] Sent: Tuesday, October 08, 2013 11:14 AM To: dev@cloudstack.apache.org Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc Bisaillon Subject: [New Feature FS] SSL Offload Support for Cloudstack Hi, I have been working on adding SSL offload functionality to cloudstack and make it work for Netscaler. I have an initial design documented at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support and I would really love your feedback. The bug for this is https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . Thanks, -Syed
RE: [New Feature FS] SSL Offload Support for Cloudstack
Darren, Murali Can you review the final patch and if acceptable merge into master. Syed the deadline is hard. I will cut the branch on 11/08 late night or early morning next day Animesh > -Original Message- > From: Syed Ahmed [mailto:sah...@cloudops.com] > Sent: Wednesday, November 06, 2013 8:26 AM > To: dev@cloudstack.apache.org > Cc: Murali Reddy; Darren Shepherd > Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack > > Hi All, > > Many thanks to Darren and Murali for reviewing my code. I feel that the > code is in a good condition to be merged into the master. I see that the > code freeze is at the end of this week. Is it possible for my patch to > be merged by then? Is it a hard deadline? > > Thanks, > -Syed > > On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote: > > Hi All, > > > > I would like to get this code into 4.3. Is it possible for this to be > > reviewed? Is there anything needed from my side? I would be glad to > > provide more information. > > > > Thanks, > > -Syed > > > > On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote: > >> Hi All, > >> > >> I have the patch for adding SSL termination support at > >> https://reviews.apache.org/r/14976/ . It would be great if this can > >> be reviewed. > >> > >> Thanks, > >> -Syed > >> > >> On 13-10-15 03:01 AM, Murali Reddy wrote: > >>> On 11/10/13 9:31 PM, "Syed Ahmed" wrote: > >>> > >>>> Thanks for your valuable feedback Murali. Here are my comments. > >>>> > >>>>> IMO, > >>>>> its better we introduce new api's say > >>>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalance > >>>>> r > >>>>> than > >>>>> force fit existing API's for associate/dis-associate certificates. > >>>> Personally, I was going to do it this way. But I am not sure how > >>>> good of an idea it is to add a new api just for this feature as I > >>>> can see assignToLoadbalancer is semantically similar. But if > >>>> everyone agrees I have no problem with it. > >>> CloudStack already has distinct API's for each of the LB > >>> sub-functionality (health check, stickiness etc) [1]. We are not > >>> adding any redundant API, so resulting API are much cleaner just > >>> managing SSL termination for a LB rule. > >>> > >>>>> On second thought may be an CloudStack usage event on assigning > >>>>> certificate seems good enough to me. > >>>> So what I got from your earlier post was that when adding a > >>>> network offering the provider can choose to enable SSL Termination > >>>> or not as it is a value added service. I was thinking of adding > >>>> "SSL termination" > >>>> under supportedservices for the createNetworkOffering API call. > >>>> And when someone calls the API to assign a cert to LB we can check > >>>> if this network offering has SSL termination enabled. Does this > make sense? > >>> So there is notion of network service and network service capability > >>> [2]. > >>> I would attribute 'SSL termination' as capability of LB service. > >>> createNetworkOffering API take a capability list. It does make sense > >>> to check if the network offering has SSL termination enabled when > >>> API to assign a cert to LB is called. Also note that, 'Network > Elements' > >>> declare > >>> their capabilities for the supported services. So it can verified > >>> that service provider for LB actually supports 'SSL termination' > >>> capability while creating network offering. > >>> > >>> > >>>> Also when you say usage event, what does this imply? I am sorry I > >>>> am not familiar with that term. Can you please elaborate. > >>> Its an event generated and persisted in the DB for every resource > >>> consumption and release. These events are used for billing etc. > >>> Please check publishUsageEvent calls in the code. > >>> > >>> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html > >>> [2] api/src/com/cloud/network/Network.java > >>> > >> > > > > >
Re: [New Feature FS] SSL Offload Support for Cloudstack
Yes, the certificates are managed separately from the Netscaler on cloudstack and get passed to the resource. Any other LB can implement the termination feature and use the certificates. On Wed 06 Nov 2013 12:36:26 PM EST, Marcus Sorensen wrote: Just want to mention that if certificates are managed, this would be fairly simple to add to VPC routers as well. The haproxy loadbalancer config would just need to be passed the cert and a slightly different config. So hopefully it has been implemented in such a way that it's easy to reuse for VPC, the certs aren't tied to netscaler objects or something like that. On Wed, Nov 6, 2013 at 9:25 AM, Syed Ahmed wrote: Hi All, Many thanks to Darren and Murali for reviewing my code. I feel that the code is in a good condition to be merged into the master. I see that the code freeze is at the end of this week. Is it possible for my patch to be merged by then? Is it a hard deadline? Thanks, -Syed On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote: Hi All, I would like to get this code into 4.3. Is it possible for this to be reviewed? Is there anything needed from my side? I would be glad to provide more information. Thanks, -Syed On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote: Hi All, I have the patch for adding SSL termination support at https://reviews.apache.org/r/14976/ . It would be great if this can be reviewed. Thanks, -Syed On 13-10-15 03:01 AM, Murali Reddy wrote: On 11/10/13 9:31 PM, "Syed Ahmed" wrote: Thanks for your valuable feedback Murali. Here are my comments. IMO, its better we introduce new api's say registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than force fit existing API's for associate/dis-associate certificates. Personally, I was going to do it this way. But I am not sure how good of an idea it is to add a new api just for this feature as I can see assignToLoadbalancer is semantically similar. But if everyone agrees I have no problem with it. CloudStack already has distinct API's for each of the LB sub-functionality (health check, stickiness etc) [1]. We are not adding any redundant API, so resulting API are much cleaner just managing SSL termination for a LB rule. On second thought may be an CloudStack usage event on assigning certificate seems good enough to me. So what I got from your earlier post was that when adding a network offering the provider can choose to enable SSL Termination or not as it is a value added service. I was thinking of adding "SSL termination" under supportedservices for the createNetworkOffering API call. And when someone calls the API to assign a cert to LB we can check if this network offering has SSL termination enabled. Does this make sense? So there is notion of network service and network service capability [2]. I would attribute 'SSL termination' as capability of LB service. createNetworkOffering API take a capability list. It does make sense to check if the network offering has SSL termination enabled when API to assign a cert to LB is called. Also note that, 'Network Elements' declare their capabilities for the supported services. So it can verified that service provider for LB actually supports 'SSL termination' capability while creating network offering. Also when you say usage event, what does this imply? I am sorry I am not familiar with that term. Can you please elaborate. Its an event generated and persisted in the DB for every resource consumption and release. These events are used for billing etc. Please check publishUsageEvent calls in the code. [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html [2] api/src/com/cloud/network/Network.java
Re: [New Feature FS] SSL Offload Support for Cloudstack
Just want to mention that if certificates are managed, this would be fairly simple to add to VPC routers as well. The haproxy loadbalancer config would just need to be passed the cert and a slightly different config. So hopefully it has been implemented in such a way that it's easy to reuse for VPC, the certs aren't tied to netscaler objects or something like that. On Wed, Nov 6, 2013 at 9:25 AM, Syed Ahmed wrote: > Hi All, > > Many thanks to Darren and Murali for reviewing my code. I feel that the code > is in a good condition to be merged into the master. I see that the code > freeze is at the end of this week. Is it possible for my patch to be merged > by then? Is it a hard deadline? > > Thanks, > -Syed > > > On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote: >> >> Hi All, >> >> I would like to get this code into 4.3. Is it possible for this to be >> reviewed? Is there anything needed from my side? I would be glad to >> provide more information. >> >> Thanks, >> -Syed >> >> On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote: >>> >>> Hi All, >>> >>> I have the patch for adding SSL termination support at >>> https://reviews.apache.org/r/14976/ . It would be great if this can be >>> reviewed. >>> >>> Thanks, >>> -Syed >>> >>> On 13-10-15 03:01 AM, Murali Reddy wrote: On 11/10/13 9:31 PM, "Syed Ahmed" wrote: > Thanks for your valuable feedback Murali. Here are my comments. > >> IMO, >> its better we introduce new api's say >> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer >> than >> force fit existing API's for associate/dis-associate certificates. > > Personally, I was going to do it this way. But I am not sure how good > of an idea it is to add a new api just for this feature as I can see > assignToLoadbalancer is semantically similar. But if everyone agrees I > have no problem with it. CloudStack already has distinct API's for each of the LB sub-functionality (health check, stickiness etc) [1]. We are not adding any redundant API, so resulting API are much cleaner just managing SSL termination for a LB rule. >> On second thought may be an CloudStack usage event on assigning >> certificate seems good enough to me. > > So what I got from your earlier post was that when adding a network > offering the provider can choose to enable SSL Termination or not > as it > is a value added service. I was thinking of adding "SSL termination" > under supportedservices for the createNetworkOffering API call. And > when someone calls the API to assign a cert to LB we can check if this > network offering has SSL termination enabled. Does this make sense? So there is notion of network service and network service capability [2]. I would attribute 'SSL termination' as capability of LB service. createNetworkOffering API take a capability list. It does make sense to check if the network offering has SSL termination enabled when API to assign a cert to LB is called. Also note that, 'Network Elements' declare their capabilities for the supported services. So it can verified that service provider for LB actually supports 'SSL termination' capability while creating network offering. > Also when you say usage event, what does this imply? I am sorry I am > not familiar with that term. Can you please elaborate. Its an event generated and persisted in the DB for every resource consumption and release. These events are used for billing etc. Please check publishUsageEvent calls in the code. [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html [2] api/src/com/cloud/network/Network.java >>> >> >> > >
Re: [New Feature FS] SSL Offload Support for Cloudstack
Hi All, Many thanks to Darren and Murali for reviewing my code. I feel that the code is in a good condition to be merged into the master. I see that the code freeze is at the end of this week. Is it possible for my patch to be merged by then? Is it a hard deadline? Thanks, -Syed On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote: Hi All, I would like to get this code into 4.3. Is it possible for this to be reviewed? Is there anything needed from my side? I would be glad to provide more information. Thanks, -Syed On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote: Hi All, I have the patch for adding SSL termination support at https://reviews.apache.org/r/14976/ . It would be great if this can be reviewed. Thanks, -Syed On 13-10-15 03:01 AM, Murali Reddy wrote: On 11/10/13 9:31 PM, "Syed Ahmed" wrote: Thanks for your valuable feedback Murali. Here are my comments. IMO, its better we introduce new api's say registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than force fit existing API's for associate/dis-associate certificates. Personally, I was going to do it this way. But I am not sure how good of an idea it is to add a new api just for this feature as I can see assignToLoadbalancer is semantically similar. But if everyone agrees I have no problem with it. CloudStack already has distinct API's for each of the LB sub-functionality (health check, stickiness etc) [1]. We are not adding any redundant API, so resulting API are much cleaner just managing SSL termination for a LB rule. On second thought may be an CloudStack usage event on assigning certificate seems good enough to me. So what I got from your earlier post was that when adding a network offering the provider can choose to enable SSL Termination or not as it is a value added service. I was thinking of adding "SSL termination" under supportedservices for the createNetworkOffering API call. And when someone calls the API to assign a cert to LB we can check if this network offering has SSL termination enabled. Does this make sense? So there is notion of network service and network service capability [2]. I would attribute 'SSL termination' as capability of LB service. createNetworkOffering API take a capability list. It does make sense to check if the network offering has SSL termination enabled when API to assign a cert to LB is called. Also note that, 'Network Elements' declare their capabilities for the supported services. So it can verified that service provider for LB actually supports 'SSL termination' capability while creating network offering. Also when you say usage event, what does this imply? I am sorry I am not familiar with that term. Can you please elaborate. Its an event generated and persisted in the DB for every resource consumption and release. These events are used for billing etc. Please check publishUsageEvent calls in the code. [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html [2] api/src/com/cloud/network/Network.java
Re: [New Feature FS] SSL Offload Support for Cloudstack
Hi All, I would like to get this code into 4.3. Is it possible for this to be reviewed? Is there anything needed from my side? I would be glad to provide more information. Thanks, -Syed On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote: Hi All, I have the patch for adding SSL termination support at https://reviews.apache.org/r/14976/ . It would be great if this can be reviewed. Thanks, -Syed On 13-10-15 03:01 AM, Murali Reddy wrote: On 11/10/13 9:31 PM, "Syed Ahmed" wrote: Thanks for your valuable feedback Murali. Here are my comments. IMO, its better we introduce new api's say registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than force fit existing API's for associate/dis-associate certificates. Personally, I was going to do it this way. But I am not sure how good of an idea it is to add a new api just for this feature as I can see assignToLoadbalancer is semantically similar. But if everyone agrees I have no problem with it. CloudStack already has distinct API's for each of the LB sub-functionality (health check, stickiness etc) [1]. We are not adding any redundant API, so resulting API are much cleaner just managing SSL termination for a LB rule. On second thought may be an CloudStack usage event on assigning certificate seems good enough to me. So what I got from your earlier post was that when adding a network offering the provider can choose to enable SSL Termination or not as it is a value added service. I was thinking of adding "SSL termination" under supportedservices for the createNetworkOffering API call. And when someone calls the API to assign a cert to LB we can check if this network offering has SSL termination enabled. Does this make sense? So there is notion of network service and network service capability [2]. I would attribute 'SSL termination' as capability of LB service. createNetworkOffering API take a capability list. It does make sense to check if the network offering has SSL termination enabled when API to assign a cert to LB is called. Also note that, 'Network Elements' declare their capabilities for the supported services. So it can verified that service provider for LB actually supports 'SSL termination' capability while creating network offering. Also when you say usage event, what does this imply? I am sorry I am not familiar with that term. Can you please elaborate. Its an event generated and persisted in the DB for every resource consumption and release. These events are used for billing etc. Please check publishUsageEvent calls in the code. [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html [2] api/src/com/cloud/network/Network.java
Re: [New Feature FS] SSL Offload Support for Cloudstack
Hi All, I have the patch for adding SSL termination support at https://reviews.apache.org/r/14976/ . It would be great if this can be reviewed. Thanks, -Syed On 13-10-15 03:01 AM, Murali Reddy wrote: On 11/10/13 9:31 PM, "Syed Ahmed" wrote: Thanks for your valuable feedback Murali. Here are my comments. IMO, its better we introduce new api's say registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than force fit existing API's for associate/dis-associate certificates. Personally, I was going to do it this way. But I am not sure how good of an idea it is to add a new api just for this feature as I can see assignToLoadbalancer is semantically similar. But if everyone agrees I have no problem with it. CloudStack already has distinct API's for each of the LB sub-functionality (health check, stickiness etc) [1]. We are not adding any redundant API, so resulting API are much cleaner just managing SSL termination for a LB rule. On second thought may be an CloudStack usage event on assigning certificate seems good enough to me. So what I got from your earlier post was that when adding a network offering the provider can choose to enable SSL Termination or not as it is a value added service. I was thinking of adding "SSL termination" under supportedservices for the createNetworkOffering API call. And when someone calls the API to assign a cert to LB we can check if this network offering has SSL termination enabled. Does this make sense? So there is notion of network service and network service capability [2]. I would attribute 'SSL termination' as capability of LB service. createNetworkOffering API take a capability list. It does make sense to check if the network offering has SSL termination enabled when API to assign a cert to LB is called. Also note that, 'Network Elements' declare their capabilities for the supported services. So it can verified that service provider for LB actually supports 'SSL termination' capability while creating network offering. Also when you say usage event, what does this imply? I am sorry I am not familiar with that term. Can you please elaborate. Its an event generated and persisted in the DB for every resource consumption and release. These events are used for billing etc. Please check publishUsageEvent calls in the code. [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html [2] api/src/com/cloud/network/Network.java
Re: [New Feature FS] SSL Offload Support for Cloudstack
Thanks Murali for your comments. I have started implementing the API which consists of mostly certificate management, which is adding/deleting and listing SSL certs. I will implement the assign to loadbalancer and the resource specific code later. Is it possible to submit my patch in two parts? The first part deals with certificate management and the second one deals with assignment of the certificate to loadbalancer. Both modules are independent and I feel like I would learn a lot as my first part is being reviewed and I can incorporate the feedback from it onto my second part. What do you guys think? Thanks -Syed On Tue 15 Oct 2013 03:01:05 AM EDT, Murali Reddy wrote: On 11/10/13 9:31 PM, "Syed Ahmed" wrote: Thanks for your valuable feedback Murali. Here are my comments. IMO, its better we introduce new api's say registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than force fit existing API's for associate/dis-associate certificates. Personally, I was going to do it this way. But I am not sure how good of an idea it is to add a new api just for this feature as I can see assignToLoadbalancer is semantically similar. But if everyone agrees I have no problem with it. CloudStack already has distinct API's for each of the LB sub-functionality (health check, stickiness etc) [1]. We are not adding any redundant API, so resulting API are much cleaner just managing SSL termination for a LB rule. On second thought may be an CloudStack usage event on assigning certificate seems good enough to me. So what I got from your earlier post was that when adding a network offering the provider can choose to enable SSL Termination or not as it is a value added service. I was thinking of adding "SSL termination" under supportedservices for the createNetworkOffering API call. And when someone calls the API to assign a cert to LB we can check if this network offering has SSL termination enabled. Does this make sense? So there is notion of network service and network service capability [2]. I would attribute 'SSL termination' as capability of LB service. createNetworkOffering API take a capability list. It does make sense to check if the network offering has SSL termination enabled when API to assign a cert to LB is called. Also note that, 'Network Elements' declare their capabilities for the supported services. So it can verified that service provider for LB actually supports 'SSL termination' capability while creating network offering. Also when you say usage event, what does this imply? I am sorry I am not familiar with that term. Can you please elaborate. Its an event generated and persisted in the DB for every resource consumption and release. These events are used for billing etc. Please check publishUsageEvent calls in the code. [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html [2] api/src/com/cloud/network/Network.java
Re: [New Feature FS] SSL Offload Support for Cloudstack
On 11/10/13 9:31 PM, "Syed Ahmed" wrote: >Thanks for your valuable feedback Murali. Here are my comments. > >> IMO, >> its better we introduce new api's say >> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than >> force fit existing API's for associate/dis-associate certificates. > >Personally, I was going to do it this way. But I am not sure how good >of an idea it is to add a new api just for this feature as I can see >assignToLoadbalancer is semantically similar. But if everyone agrees I >have no problem with it. CloudStack already has distinct API's for each of the LB sub-functionality (health check, stickiness etc) [1]. We are not adding any redundant API, so resulting API are much cleaner just managing SSL termination for a LB rule. > >> On second thought may be an CloudStack usage event on assigning >> certificate seems good enough to me. > >So what I got from your earlier post was that when adding a network >offering the provider can choose to enable SSL Termination or not as it >is a value added service. I was thinking of adding "SSL termination" >under supportedservices for the createNetworkOffering API call. And >when someone calls the API to assign a cert to LB we can check if this >network offering has SSL termination enabled. Does this make sense? So there is notion of network service and network service capability [2]. I would attribute 'SSL termination' as capability of LB service. createNetworkOffering API take a capability list. It does make sense to check if the network offering has SSL termination enabled when API to assign a cert to LB is called. Also note that, 'Network Elements' declare their capabilities for the supported services. So it can verified that service provider for LB actually supports 'SSL termination' capability while creating network offering. > >Also when you say usage event, what does this imply? I am sorry I am >not familiar with that term. Can you please elaborate. Its an event generated and persisted in the DB for every resource consumption and release. These events are used for billing etc. Please check publishUsageEvent calls in the code. [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html [2] api/src/com/cloud/network/Network.java
Re: [New Feature FS] SSL Offload Support for Cloudstack
Thanks for your valuable feedback Murali. Here are my comments. IMO, its better we introduce new api's say registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than force fit existing API's for associate/dis-associate certificates. Personally, I was going to do it this way. But I am not sure how good of an idea it is to add a new api just for this feature as I can see assignToLoadbalancer is semantically similar. But if everyone agrees I have no problem with it. On second thought may be an CloudStack usage event on assigning certificate seems good enough to me. So what I got from your earlier post was that when adding a network offering the provider can choose to enable SSL Termination or not as it is a value added service. I was thinking of adding "SSL termination" under supportedservices for the createNetworkOffering API call. And when someone calls the API to assign a cert to LB we can check if this network offering has SSL termination enabled. Does this make sense? Also when you say usage event, what does this imply? I am sorry I am not familiar with that term. Can you please elaborate. Thanks -Syed On Fri 11 Oct 2013 09:03:45 AM EDT, Murali Reddy wrote: On 09/10/13 8:08 PM, "Syed Ahmed" wrote: Thanks Murali for your response. - any reason why you choose assignTo/RemoveFrom load balancer rule API's I thought this made more sense than create/updateLoadbalancerRule as we would have to call update to delete a cert which I find somewhat confusing. Also this is semantically similar to attaching instances as in you have a separate entity which is being bound to different LBs. We will be just overloading the assignTo/RemoveFrom load balancer rule API's for associate/dis-associte certificate with load balancer rule. - to me SSL termination is value added service from providers perspective, So only if network offering permits, SSL termination can be used. Got it. This seems the logical way. Good point. On second thought may be an CloudStack usage event on assigning certificate seems good enough to me. Would it be a good Idea to add protocol to the createLoadBalancer API. I think this makes sense in the long run as currently I cannot create a HTTP loadbalncer for port 8080 from cloudstack. Yes, its good we introduce protocol in the API, and make it optional parameter. Currently CloudStack marks protocol as TCP by default and load balancer implementation layer corresponding to HAProxy, F5, NetScaler we are inferring protocol from the ports. So on upgrade just ensure we don't break backward compatibility of the existing load balancer rules.
Re: [New Feature FS] SSL Offload Support for Cloudstack
On 09/10/13 8:08 PM, "Syed Ahmed" wrote: >Thanks Murali for your response. > >> - any reason why you choose assignTo/RemoveFrom load balancer rule API's > >I thought this made more sense than create/updateLoadbalancerRule as >we would have to call update to delete a cert which I find somewhat >confusing. Also this is semantically similar to attaching instances as >in you have a separate entity which is being bound to different LBs. We will be just overloading the assignTo/RemoveFrom load balancer rule API's for associate/dis-associte certificate with load balancer rule. IMO, its better we introduce new api's say registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than force fit existing API's for associate/dis-associate certificates. > >> - to me SSL termination is value added service from providers >>perspective, >> So only if network offering permits, SSL termination can be used. > >Got it. This seems the logical way. Good point. On second thought may be an CloudStack usage event on assigning certificate seems good enough to me. > >Would it be a good Idea to add protocol to the createLoadBalancer API. >I think this makes sense in the long run as currently I cannot create >a HTTP loadbalncer for port 8080 from cloudstack. Yes, its good we introduce protocol in the API, and make it optional parameter. Currently CloudStack marks protocol as TCP by default and load balancer implementation layer corresponding to HAProxy, F5, NetScaler we are inferring protocol from the ports. So on upgrade just ensure we don't break backward compatibility of the existing load balancer rules.
Re: [New Feature FS] SSL Offload Support for Cloudstack
Thanks Murali for your response. > - any reason why you choose assignTo/RemoveFrom load balancer rule API's I thought this made more sense than create/updateLoadbalancerRule as we would have to call update to delete a cert which I find somewhat confusing. Also this is semantically similar to attaching instances as in you have a separate entity which is being bound to different LBs. > - to me SSL termination is value added service from providers perspective, > So only if network offering permits, SSL termination can be used. Got it. This seems the logical way. Good point. > I see session persistence based on SSL session id's please see if > this can supported. I was looking at persistence based on SSL session id's [1] and found that this is supported for SSL bridge type of configuration where netscaler just bridges the data without any encryption/decryption. I am not sure about health checks and autoscale. I will look that up. > - on the requirement #4, don't infer protocol based on the public/private > ports and impose restrictions. Current createLoadBalancer API does not > take protocol parameter so its inferred at device layer. NetScaler seems > to support SSL with other TCP ports as well. Would it be a good Idea to add protocol to the createLoadBalancer API. I think this makes sense in the long run as currently I cannot create a HTTP loadbalncer for port 8080 from cloudstack. > One general implementation note, network rules can be reprogrammed. So > operations to configure SSL cert, binding cert to virtual server etc need > to be idempotent at NetScaler resource. Thanks. I'll keep that in mind when implementing the resource layer. Thank a lot again for the replies. This is really helpful. -- REFERENCES -- [1] http://support.citrix.com/proddocs/topic/netscaler-load-balancing-93/ns-lb-persistence-configuring-ssl-session-id-tsk.html -Syed On Wed, Oct 9, 2013 at 5:57 AM, Murali Reddy wrote: > Thanks Syed for the FS. > > Couple of comments: > > - any reason why you choose assignTo/RemoveFrom load balancer rule API's > to assign/remove certificate to LB rules? These api's are basically for > controlling VM membership with a load balancer rule. Can > create/updateLoadBalancerRule api's b used for registering and > de-registering certificate with load balancer rule? > > - to me SSL termination is value added service from providers perspective, > its better we expose service differentiation in the network offering (e.g > dedicated load balancer capability of LB service in the network offering). > So only if network offering permits, SSL termination can be used. > > - does adding SSL termination support to load balancer affect/complement > current session persistence, health monitoring, auto scale functionality > anyway? I see session persistence based on SSL session id's please see if > this can supported. > > - as commented by other, fail fast at service layer on invalid certificate. > > - on the requirement #4, don't infer protocol based on the public/private > ports and impose restrictions. Current createLoadBalancer API does not > take protocol parameter so its inferred at device layer. NetScaler seems > to support SSL with other TCP ports as well. > > One general implementation note, network rules can be reprogrammed. So > operations to configure SSL cert, binding cert to virtual server etc need > to be idempotent at NetScaler resource. > > [1] > http://support.citrix.com/proddocs/topic/netscaler-ssl-93/ns-ssl-offloading > -other-tcp-protocols-tsk.html > > On 08/10/13 11:44 PM, "Syed Ahmed" wrote: > >>Hi, >> >>I have been working on adding SSL offload functionality to cloudstack >>and make it work for Netscaler. I have an initial design documented at >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Supp >>ort >>and I would really love your feedback. The bug for this is >>https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . >> >>Thanks, >>-Syed >> >> >> > >
Re: [New Feature FS] SSL Offload Support for Cloudstack
> Additionally, I don't see that the code handles the > chain also. I could be wrong, but just from reading the code it seems > to assume the "cert" string produces a single cert. Correct me if I'm > wrong. You are right. This just handles a single certificate. It does not handle trust chains. > (Don't let people remove a cert that is currently used). You bring up an good point. I assumed that if the user deletes a certificate, we internally go ahead and remove all the bindings from LB rules. This happens with VM instances. The difference that I see is if you remove the certificate, the LB goes down but if you remove an instance the LB may still work. > I'm guessing you won't need to create any > new managers, so that probably won't apply. If I am giving the functionality of updating a certificate then my CertificateService should call the resource layer for updating on the device as well. Now from you mail what I understand is this has to be done by creating a manager. So either we go ahead and drop the updateCertificate call or we will have to add a manager for this. I prefer dropping the updateCert call as I don't see anyone updating cert contents frequently. Thanks -Syed On Wed, Oct 9, 2013 at 1:02 AM, Darren Shepherd wrote: > I'm not too sure that its going to be worth it to reuse > KeyStoreManager. That code is for storage of certs for the systemvm. > So you need to ensure that your changes don't overlap with the > systemvm code. Additionally, I don't see that the code handles the > chain also. I could be wrong, but just from reading the code it seems > to assume the "cert" string produces a single cert. Correct me if I'm > wrong. > > The absolute key thing for this feature, in my mind, is getting the > input validation right. If you don't give useful errors, you'll be > handling requests from people not being able to insert a cert, and the > default errors from java are typically not very useful. > > Regarding design. API Commands should synchronously call a Service > class, this is the create() method of an async command or execute() of > a non async command. That service method should do no more than input > validation and saving things to the database. If you need to > communicate to resources, then it should be an async api command. The > async portion of the API command, this would be the execute() method, > should also call the service class. Since you ideally did all the > input validation in the sync portion, not much validation should > happen at this point. But there may be some more intensive validation > you want to do at this point. After validation, the service class > should call the manager. The manager does the real business logic. > > So you have two groups of functionality. Managing SSL certs and then > apply SSL to LB. For the SSL cert management, I'd probably create a > new CertificateService. I think all the functionality is really just > manipulating the DB, so all the calls can be sync. (Don't let people > remove a cert that is currently used). > Now one of my pet peeves in ACS is that Service interface and Manager > interface are always implemented by the same class. This is bad, you > end up bluring the lines of the architecture and code becomes a big > blob, so avoid doing that. > > Darren > > On Tue, Oct 8, 2013 at 4:44 PM, Syed Ahmed wrote: >> Thanks Edison for the reply. >> >> I see that there is already an implementation of KeystoreManager which does >> certificate validation and saves it in the keystore table. Also, the API >> (UploadCustomCertificate) is only callable from admin. I could add >> functionality to this class for handling certificate chain and also make >> sure the table stores the account_id as well. We could reduce creating one >> table by reusing the keystore table. >> >> I have a question about terminology. What is a service and a manager because >> I see them both being used. In my case, I assume that my CertificateService >> will have the KeystoreManager injected and the Service will serve as a proxy >> between the Resource layer and the KeystoreManager which is the Db layer. >> Will this approach work? >> >> Thanks >> -Syed >> >> >> >> On Tue 08 Oct 2013 06:56:34 PM EDT, Edison Su wrote: >>> >>> There is command in ACS, UploadCustomCertificateCmd, which can receive ssl >>> cert, key can chain as input. Maybe can share some code? >>> >>>> -Original Message- >>>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] >>>> Sent: Tuesday, October 08, 2013 1:54 PM >&
Re: [New Feature FS] SSL Offload Support for Cloudstack
Thanks Syed for the FS. Couple of comments: - any reason why you choose assignTo/RemoveFrom load balancer rule API's to assign/remove certificate to LB rules? These api's are basically for controlling VM membership with a load balancer rule. Can create/updateLoadBalancerRule api's b used for registering and de-registering certificate with load balancer rule? - to me SSL termination is value added service from providers perspective, its better we expose service differentiation in the network offering (e.g dedicated load balancer capability of LB service in the network offering). So only if network offering permits, SSL termination can be used. - does adding SSL termination support to load balancer affect/complement current session persistence, health monitoring, auto scale functionality anyway? I see session persistence based on SSL session id's please see if this can supported. - as commented by other, fail fast at service layer on invalid certificate. - on the requirement #4, don't infer protocol based on the public/private ports and impose restrictions. Current createLoadBalancer API does not take protocol parameter so its inferred at device layer. NetScaler seems to support SSL with other TCP ports as well. One general implementation note, network rules can be reprogrammed. So operations to configure SSL cert, binding cert to virtual server etc need to be idempotent at NetScaler resource. [1] http://support.citrix.com/proddocs/topic/netscaler-ssl-93/ns-ssl-offloading -other-tcp-protocols-tsk.html On 08/10/13 11:44 PM, "Syed Ahmed" wrote: >Hi, > >I have been working on adding SSL offload functionality to cloudstack >and make it work for Netscaler. I have an initial design documented at >https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Supp >ort >and I would really love your feedback. The bug for this is >https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . > >Thanks, >-Syed > > >
Re: [New Feature FS] SSL Offload Support for Cloudstack
I'm not too sure that its going to be worth it to reuse KeyStoreManager. That code is for storage of certs for the systemvm. So you need to ensure that your changes don't overlap with the systemvm code. Additionally, I don't see that the code handles the chain also. I could be wrong, but just from reading the code it seems to assume the "cert" string produces a single cert. Correct me if I'm wrong. The absolute key thing for this feature, in my mind, is getting the input validation right. If you don't give useful errors, you'll be handling requests from people not being able to insert a cert, and the default errors from java are typically not very useful. Regarding design. API Commands should synchronously call a Service class, this is the create() method of an async command or execute() of a non async command. That service method should do no more than input validation and saving things to the database. If you need to communicate to resources, then it should be an async api command. The async portion of the API command, this would be the execute() method, should also call the service class. Since you ideally did all the input validation in the sync portion, not much validation should happen at this point. But there may be some more intensive validation you want to do at this point. After validation, the service class should call the manager. The manager does the real business logic. So you have two groups of functionality. Managing SSL certs and then apply SSL to LB. For the SSL cert management, I'd probably create a new CertificateService. I think all the functionality is really just manipulating the DB, so all the calls can be sync. (Don't let people remove a cert that is currently used). For associating SSL cert to LB, you can probably piggy back on the existing LB services/managers. Now one of my pet peeves in ACS is that Service interface and Manager interface are always implemented by the same class. This is bad, you end up bluring the lines of the architecture and code becomes a big blob, so avoid doing that. I'm guessing you won't need to create any new managers, so that probably won't apply. Darren On Tue, Oct 8, 2013 at 4:44 PM, Syed Ahmed wrote: > Thanks Edison for the reply. > > I see that there is already an implementation of KeystoreManager which does > certificate validation and saves it in the keystore table. Also, the API > (UploadCustomCertificate) is only callable from admin. I could add > functionality to this class for handling certificate chain and also make > sure the table stores the account_id as well. We could reduce creating one > table by reusing the keystore table. > > I have a question about terminology. What is a service and a manager because > I see them both being used. In my case, I assume that my CertificateService > will have the KeystoreManager injected and the Service will serve as a proxy > between the Resource layer and the KeystoreManager which is the Db layer. > Will this approach work? > > Thanks > -Syed > > > > On Tue 08 Oct 2013 06:56:34 PM EDT, Edison Su wrote: >> >> There is command in ACS, UploadCustomCertificateCmd, which can receive ssl >> cert, key can chain as input. Maybe can share some code? >> >>> -Original Message----- >>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] >>> Sent: Tuesday, October 08, 2013 1:54 PM >>> To: dev@cloudstack.apache.org >>> Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack >>> >>> The API should do input validation on the SSL cert, key and chain. >>> Getting those three pieces of info is usually difficult for most people >>> to get >>> right as they don't really know what those three things are. There's >>> about a >>> 80% chance most calls will fail. If you rely on the provider it will >>> probably just >>> give back some general failure message that we won't be able to map back >>> to >>> the user as useful information. >>> >>> I would implement the cert management as a separate CertificateService. >>> >>> Darren >>> >>> On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed >>> wrote: >>>> >>>> A question about implementation. I was looking at other commands and >>>> the >>>> execute() method for each of the other commands seem to call a service >>>> ( _lbservice for example ) which takes care of updating the DB and >>>> calling the resource layer. Should the Certificate management be >>>> implemented as a service or is there something else that I can use? An >>>> example would be immense
Re: [New Feature FS] SSL Offload Support for Cloudstack
Thanks Edison for the reply. I see that there is already an implementation of KeystoreManager which does certificate validation and saves it in the keystore table. Also, the API (UploadCustomCertificate) is only callable from admin. I could add functionality to this class for handling certificate chain and also make sure the table stores the account_id as well. We could reduce creating one table by reusing the keystore table. I have a question about terminology. What is a service and a manager because I see them both being used. In my case, I assume that my CertificateService will have the KeystoreManager injected and the Service will serve as a proxy between the Resource layer and the KeystoreManager which is the Db layer. Will this approach work? Thanks -Syed On Tue 08 Oct 2013 06:56:34 PM EDT, Edison Su wrote: There is command in ACS, UploadCustomCertificateCmd, which can receive ssl cert, key can chain as input. Maybe can share some code? -Original Message- From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] Sent: Tuesday, October 08, 2013 1:54 PM To: dev@cloudstack.apache.org Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack The API should do input validation on the SSL cert, key and chain. Getting those three pieces of info is usually difficult for most people to get right as they don't really know what those three things are. There's about a 80% chance most calls will fail. If you rely on the provider it will probably just give back some general failure message that we won't be able to map back to the user as useful information. I would implement the cert management as a separate CertificateService. Darren On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed wrote: A question about implementation. I was looking at other commands and the execute() method for each of the other commands seem to call a service ( _lbservice for example ) which takes care of updating the DB and calling the resource layer. Should the Certificate management be implemented as a service or is there something else that I can use? An example would be immensely helpful. Thanks -Syed On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote: Thanks for the feedback guys. Really appreciate it. 1) Changing the name to SSL Termination. I don't have a problem with that. I was looking at Netscaler all the time and they call it SSL offloading. But I agree that termination is a more general term. I have changed the name. The new page is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Terminatio n+Support 2) Specify the protocol type. Currently the protocol type of a loadbalncer gets set by checking the source and destination port ( see getNetScalerProtocol() in NetscalerResouce.java ) . So, we should change that and add another optional field in the createLoadBalancerRule for protocol. 3) Certificate chain as a seperate parameter. Again, I was looking at Netscaler as an example but separating the chain and certificate makes sense. I have updated the document accordingly. I was assuming that the certificate parsing/validation would be done by the device and we would just pass the certficate data as-is. But if we are adding chains separately, we should have the ability to parse and combine the chain and certificate for some devices as you mentioned. Thanks -Syed On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote: On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote: Technicality here, can we call the functionality SSL termination? While technically we are "offloading" ssl from the VM, offloading typically carries a connotation that its being done in hardware. So we are really talking about SSL termination. +1 - completely agree. There's certainly the possibility of an *implementation* being true offloading, but I'd generalize to "termination" to account for a non-hardware offload of the crypto processing. Couple comments. I wouldn't want to assume anything about SSL based on port numbers. So instead specify the protocol (http/https/ssl/tcp) for the front and back side of the load balancer. Additionally, I'd prefer the chain not be in the cert. When configuring some backends you need the cert and chain separate. It would be easier if they were stored that way. Otherwise you have to do logic of parsing all the certs in the "keystore" and look for the one that matches the key. Also +1 to this. Cert chains may be optional, certainly, but should actually be separate from the actual cert in the configuration. The implementation may need to combine them into one document, but that's implementation specific. Otherwise, awesome feature. I'll tell you, from an impl perspective, parsing and validating the SSL certs is a pain. I can probably find some java code to help out here on this as I've done this before in the past. Yes, this is
RE: [New Feature FS] SSL Offload Support for Cloudstack
There is command in ACS, UploadCustomCertificateCmd, which can receive ssl cert, key can chain as input. Maybe can share some code? > -Original Message- > From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] > Sent: Tuesday, October 08, 2013 1:54 PM > To: dev@cloudstack.apache.org > Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack > > The API should do input validation on the SSL cert, key and chain. > Getting those three pieces of info is usually difficult for most people to get > right as they don't really know what those three things are. There's about a > 80% chance most calls will fail. If you rely on the provider it will > probably just > give back some general failure message that we won't be able to map back to > the user as useful information. > > I would implement the cert management as a separate CertificateService. > > Darren > > On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed > wrote: > > A question about implementation. I was looking at other commands and > > the > > execute() method for each of the other commands seem to call a service > > ( _lbservice for example ) which takes care of updating the DB and > > calling the resource layer. Should the Certificate management be > > implemented as a service or is there something else that I can use? An > > example would be immensely helpful. > > > > Thanks > > -Syed > > > > > > > > On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote: > >> > >> Thanks for the feedback guys. Really appreciate it. > >> > >> 1) Changing the name to SSL Termination. > >> > >> I don't have a problem with that. I was looking at Netscaler all the > >> time and they call it SSL offloading. But I agree that termination is > >> a more general term. > >> I have changed the name. The new page is at > >> > >> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Terminatio > >> n+Support > >> > >> > >> 2) Specify the protocol type. > >> > >> Currently the protocol type of a loadbalncer gets set by checking the > >> source and destination port ( see getNetScalerProtocol() in > >> NetscalerResouce.java ) . So, we should change that and add another > >> optional field in the createLoadBalancerRule for protocol. > >> > >> 3) Certificate chain as a seperate parameter. > >> > >> Again, I was looking at Netscaler as an example but separating the > >> chain and certificate makes sense. I have updated the document > >> accordingly. > >> > >> I was assuming that the certificate parsing/validation would be done > >> by the device and we would just pass the certficate data as-is. But > >> if we are adding chains separately, we should have the ability to > >> parse and combine the chain and certificate for some devices as you > mentioned. > >> > >> Thanks > >> -Syed > >> > >> > >> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote: > >>> > >>> > >>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote: > >>>> > >>>> > >>>> Technicality here, can we call the functionality SSL termination? > >>>> While technically we are "offloading" ssl from the VM, offloading > >>>> typically carries a connotation that its being done in hardware. So > >>>> we are really talking about SSL termination. > >>> > >>> > >>> > >>> +1 - completely agree. There's certainly the possibility of an > >>> *implementation* being true offloading, but I'd generalize to > >>> "termination" to account for a non-hardware offload of the crypto > >>> processing. > >>> > >>>> > >>>> > >>>> Couple comments. I wouldn't want to assume anything about SSL > based > >>>> on port numbers. So instead specify the protocol > >>>> (http/https/ssl/tcp) for the front and back side of the load > >>>> balancer. Additionally, I'd prefer the chain not be in the cert. > >>>> When configuring some backends you need the cert and chain > >>>> separate. It would be easier if they were stored that way. > >>>> Otherwise you have to do logic of parsing all the certs in the "keystore" > and look for the one that matches the key. > >>> > >>> > >>> > >>
Re: [New Feature FS] SSL Offload Support for Cloudstack
BouncyCastle, its already in ACS. Off list I'll send you some sample code on how to validate this stuff. Darren On Tue, Oct 8, 2013 at 1:58 PM, Syed Ahmed wrote: > Thanks Darren for your reply. > > Do you happen to have any info on a library that I can use for certificate > validation? > > Thanks, > -Syed > > > > On Tue 08 Oct 2013 04:53:40 PM EDT, Darren Shepherd wrote: >> >> The API should do input validation on the SSL cert, key and chain. >> Getting those three pieces of info is usually difficult for most >> people to get right as they don't really know what those three things >> are. There's about a 80% chance most calls will fail. If you rely on >> the provider it will probably just give back some general failure >> message that we won't be able to map back to the user as useful >> information. >> >> I would implement the cert management as a separate CertificateService. >> >> Darren >> >> On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed >> wrote: >>> >>> A question about implementation. I was looking at other commands and the >>> execute() method for each of the other commands seem to call a service ( >>> _lbservice for example ) which takes care of updating the DB and calling >>> the >>> resource layer. Should the Certificate management be implemented as a >>> service or is there something else that I can use? An example would be >>> immensely helpful. >>> >>> Thanks >>> -Syed >>> >>> >>> >>> On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote: Thanks for the feedback guys. Really appreciate it. 1) Changing the name to SSL Termination. I don't have a problem with that. I was looking at Netscaler all the time and they call it SSL offloading. But I agree that termination is a more general term. I have changed the name. The new page is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support 2) Specify the protocol type. Currently the protocol type of a loadbalncer gets set by checking the source and destination port ( see getNetScalerProtocol() in NetscalerResouce.java ) . So, we should change that and add another optional field in the createLoadBalancerRule for protocol. 3) Certificate chain as a seperate parameter. Again, I was looking at Netscaler as an example but separating the chain and certificate makes sense. I have updated the document accordingly. I was assuming that the certificate parsing/validation would be done by the device and we would just pass the certficate data as-is. But if we are adding chains separately, we should have the ability to parse and combine the chain and certificate for some devices as you mentioned. Thanks -Syed On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote: > > > > On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote: >> >> >> >> Technicality here, can we call the functionality SSL termination? >> While technically we are "offloading" ssl from the VM, offloading >> typically carries a connotation that its being done in hardware. So >> we are really talking about SSL termination. > > > > > +1 - completely agree. There's certainly the possibility of an > *implementation* being true offloading, but I'd generalize to > "termination" to account for a non-hardware offload of the crypto > processing. > >> >> >> Couple comments. I wouldn't want to assume anything about SSL based >> on port numbers. So instead specify the protocol (http/https/ssl/tcp) >> for the front and back side of the load balancer. Additionally, I'd >> prefer the chain not be in the cert. When configuring some backends >> you need the cert and chain separate. It would be easier if they were >> stored that way. Otherwise you have to do logic of parsing all the >> certs in the "keystore" and look for the one that matches the key. > > > > > Also +1 to this. Cert chains may be optional, certainly, but should > actually be separate from the actual cert in the configuration. The > implementation may need to combine them into one document, but that's > implementation specific. > >> >> >> Otherwise, awesome feature. I'll tell you, from an impl perspective, >> parsing and validating the SSL certs is a pain. I can probably find >> some java code to help out here on this as I've done this before in >> the past. > > > > > Yes, this is a sorely needed feature. I'm happy to see this be added to > the Netscaler plugin, and await a time when HA proxy has a stable > release that includes SSL term. > >> >> >> Darren >> >> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed >> wrote: >>> >>> >>> >>> Hi, >>> >>> I have been working on addi
Re: [New Feature FS] SSL Offload Support for Cloudstack
Thanks Darren for your reply. Do you happen to have any info on a library that I can use for certificate validation? Thanks, -Syed On Tue 08 Oct 2013 04:53:40 PM EDT, Darren Shepherd wrote: The API should do input validation on the SSL cert, key and chain. Getting those three pieces of info is usually difficult for most people to get right as they don't really know what those three things are. There's about a 80% chance most calls will fail. If you rely on the provider it will probably just give back some general failure message that we won't be able to map back to the user as useful information. I would implement the cert management as a separate CertificateService. Darren On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed wrote: A question about implementation. I was looking at other commands and the execute() method for each of the other commands seem to call a service ( _lbservice for example ) which takes care of updating the DB and calling the resource layer. Should the Certificate management be implemented as a service or is there something else that I can use? An example would be immensely helpful. Thanks -Syed On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote: Thanks for the feedback guys. Really appreciate it. 1) Changing the name to SSL Termination. I don't have a problem with that. I was looking at Netscaler all the time and they call it SSL offloading. But I agree that termination is a more general term. I have changed the name. The new page is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support 2) Specify the protocol type. Currently the protocol type of a loadbalncer gets set by checking the source and destination port ( see getNetScalerProtocol() in NetscalerResouce.java ) . So, we should change that and add another optional field in the createLoadBalancerRule for protocol. 3) Certificate chain as a seperate parameter. Again, I was looking at Netscaler as an example but separating the chain and certificate makes sense. I have updated the document accordingly. I was assuming that the certificate parsing/validation would be done by the device and we would just pass the certficate data as-is. But if we are adding chains separately, we should have the ability to parse and combine the chain and certificate for some devices as you mentioned. Thanks -Syed On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote: On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote: Technicality here, can we call the functionality SSL termination? While technically we are "offloading" ssl from the VM, offloading typically carries a connotation that its being done in hardware. So we are really talking about SSL termination. +1 - completely agree. There's certainly the possibility of an *implementation* being true offloading, but I'd generalize to "termination" to account for a non-hardware offload of the crypto processing. Couple comments. I wouldn't want to assume anything about SSL based on port numbers. So instead specify the protocol (http/https/ssl/tcp) for the front and back side of the load balancer. Additionally, I'd prefer the chain not be in the cert. When configuring some backends you need the cert and chain separate. It would be easier if they were stored that way. Otherwise you have to do logic of parsing all the certs in the "keystore" and look for the one that matches the key. Also +1 to this. Cert chains may be optional, certainly, but should actually be separate from the actual cert in the configuration. The implementation may need to combine them into one document, but that's implementation specific. Otherwise, awesome feature. I'll tell you, from an impl perspective, parsing and validating the SSL certs is a pain. I can probably find some java code to help out here on this as I've done this before in the past. Yes, this is a sorely needed feature. I'm happy to see this be added to the Netscaler plugin, and await a time when HA proxy has a stable release that includes SSL term. Darren On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed wrote: Hi, I have been working on adding SSL offload functionality to cloudstack and make it work for Netscaler. I have an initial design documented at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support and I would really love your feedback. The bug for this is https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . Thanks, -Syed
Re: [New Feature FS] SSL Offload Support for Cloudstack
The API should do input validation on the SSL cert, key and chain. Getting those three pieces of info is usually difficult for most people to get right as they don't really know what those three things are. There's about a 80% chance most calls will fail. If you rely on the provider it will probably just give back some general failure message that we won't be able to map back to the user as useful information. I would implement the cert management as a separate CertificateService. Darren On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed wrote: > A question about implementation. I was looking at other commands and the > execute() method for each of the other commands seem to call a service ( > _lbservice for example ) which takes care of updating the DB and calling the > resource layer. Should the Certificate management be implemented as a > service or is there something else that I can use? An example would be > immensely helpful. > > Thanks > -Syed > > > > On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote: >> >> Thanks for the feedback guys. Really appreciate it. >> >> 1) Changing the name to SSL Termination. >> >> I don't have a problem with that. I was looking at Netscaler all the time >> and they call it SSL offloading. But I agree that termination is a >> more general term. >> I have changed the name. The new page is at >> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support >> >> >> 2) Specify the protocol type. >> >> Currently the protocol type of a loadbalncer gets set by checking the >> source and destination port ( see getNetScalerProtocol() in >> NetscalerResouce.java ) . So, we should change that and add another >> optional field in the createLoadBalancerRule for protocol. >> >> 3) Certificate chain as a seperate parameter. >> >> Again, I was looking at Netscaler as an example but separating the >> chain and certificate makes sense. I have updated the document >> accordingly. >> >> I was assuming that the certificate parsing/validation would be done >> by the device and we would just pass the certficate data as-is. But if >> we are adding chains separately, we should have the ability to parse >> and combine the chain and certificate for some devices as you mentioned. >> >> Thanks >> -Syed >> >> >> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote: >>> >>> >>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote: Technicality here, can we call the functionality SSL termination? While technically we are "offloading" ssl from the VM, offloading typically carries a connotation that its being done in hardware. So we are really talking about SSL termination. >>> >>> >>> >>> +1 - completely agree. There's certainly the possibility of an >>> *implementation* being true offloading, but I'd generalize to >>> "termination" to account for a non-hardware offload of the crypto >>> processing. >>> Couple comments. I wouldn't want to assume anything about SSL based on port numbers. So instead specify the protocol (http/https/ssl/tcp) for the front and back side of the load balancer. Additionally, I'd prefer the chain not be in the cert. When configuring some backends you need the cert and chain separate. It would be easier if they were stored that way. Otherwise you have to do logic of parsing all the certs in the "keystore" and look for the one that matches the key. >>> >>> >>> >>> Also +1 to this. Cert chains may be optional, certainly, but should >>> actually be separate from the actual cert in the configuration. The >>> implementation may need to combine them into one document, but that's >>> implementation specific. >>> Otherwise, awesome feature. I'll tell you, from an impl perspective, parsing and validating the SSL certs is a pain. I can probably find some java code to help out here on this as I've done this before in the past. >>> >>> >>> >>> Yes, this is a sorely needed feature. I'm happy to see this be added to >>> the Netscaler plugin, and await a time when HA proxy has a stable >>> release that includes SSL term. >>> Darren On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed wrote: > > > Hi, > > I have been working on adding SSL offload functionality to > cloudstack and > make it work for Netscaler. I have an initial design documented at > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support > > and I would really love your feedback. The bug for this is > https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . > > Thanks, > -Syed > > >>> >> >> > >
Re: [New Feature FS] SSL Offload Support for Cloudstack
A question about implementation. I was looking at other commands and the execute() method for each of the other commands seem to call a service ( _lbservice for example ) which takes care of updating the DB and calling the resource layer. Should the Certificate management be implemented as a service or is there something else that I can use? An example would be immensely helpful. Thanks -Syed On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote: Thanks for the feedback guys. Really appreciate it. 1) Changing the name to SSL Termination. I don't have a problem with that. I was looking at Netscaler all the time and they call it SSL offloading. But I agree that termination is a more general term. I have changed the name. The new page is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support 2) Specify the protocol type. Currently the protocol type of a loadbalncer gets set by checking the source and destination port ( see getNetScalerProtocol() in NetscalerResouce.java ) . So, we should change that and add another optional field in the createLoadBalancerRule for protocol. 3) Certificate chain as a seperate parameter. Again, I was looking at Netscaler as an example but separating the chain and certificate makes sense. I have updated the document accordingly. I was assuming that the certificate parsing/validation would be done by the device and we would just pass the certficate data as-is. But if we are adding chains separately, we should have the ability to parse and combine the chain and certificate for some devices as you mentioned. Thanks -Syed On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote: On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote: Technicality here, can we call the functionality SSL termination? While technically we are "offloading" ssl from the VM, offloading typically carries a connotation that its being done in hardware. So we are really talking about SSL termination. +1 - completely agree. There's certainly the possibility of an *implementation* being true offloading, but I'd generalize to "termination" to account for a non-hardware offload of the crypto processing. Couple comments. I wouldn't want to assume anything about SSL based on port numbers. So instead specify the protocol (http/https/ssl/tcp) for the front and back side of the load balancer. Additionally, I'd prefer the chain not be in the cert. When configuring some backends you need the cert and chain separate. It would be easier if they were stored that way. Otherwise you have to do logic of parsing all the certs in the "keystore" and look for the one that matches the key. Also +1 to this. Cert chains may be optional, certainly, but should actually be separate from the actual cert in the configuration. The implementation may need to combine them into one document, but that's implementation specific. Otherwise, awesome feature. I'll tell you, from an impl perspective, parsing and validating the SSL certs is a pain. I can probably find some java code to help out here on this as I've done this before in the past. Yes, this is a sorely needed feature. I'm happy to see this be added to the Netscaler plugin, and await a time when HA proxy has a stable release that includes SSL term. Darren On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed wrote: Hi, I have been working on adding SSL offload functionality to cloudstack and make it work for Netscaler. I have an initial design documented at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support and I would really love your feedback. The bug for this is https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . Thanks, -Syed
Re: [New Feature FS] SSL Offload Support for Cloudstack
Thanks for the feedback guys. Really appreciate it. 1) Changing the name to SSL Termination. I don't have a problem with that. I was looking at Netscaler all the time and they call it SSL offloading. But I agree that termination is a more general term. I have changed the name. The new page is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support 2) Specify the protocol type. Currently the protocol type of a loadbalncer gets set by checking the source and destination port ( see getNetScalerProtocol() in NetscalerResouce.java ) . So, we should change that and add another optional field in the createLoadBalancerRule for protocol. 3) Certificate chain as a seperate parameter. Again, I was looking at Netscaler as an example but separating the chain and certificate makes sense. I have updated the document accordingly. I was assuming that the certificate parsing/validation would be done by the device and we would just pass the certficate data as-is. But if we are adding chains separately, we should have the ability to parse and combine the chain and certificate for some devices as you mentioned. Thanks -Syed On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote: On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote: Technicality here, can we call the functionality SSL termination? While technically we are "offloading" ssl from the VM, offloading typically carries a connotation that its being done in hardware. So we are really talking about SSL termination. +1 - completely agree. There's certainly the possibility of an *implementation* being true offloading, but I'd generalize to "termination" to account for a non-hardware offload of the crypto processing. Couple comments. I wouldn't want to assume anything about SSL based on port numbers. So instead specify the protocol (http/https/ssl/tcp) for the front and back side of the load balancer. Additionally, I'd prefer the chain not be in the cert. When configuring some backends you need the cert and chain separate. It would be easier if they were stored that way. Otherwise you have to do logic of parsing all the certs in the "keystore" and look for the one that matches the key. Also +1 to this. Cert chains may be optional, certainly, but should actually be separate from the actual cert in the configuration. The implementation may need to combine them into one document, but that's implementation specific. Otherwise, awesome feature. I'll tell you, from an impl perspective, parsing and validating the SSL certs is a pain. I can probably find some java code to help out here on this as I've done this before in the past. Yes, this is a sorely needed feature. I'm happy to see this be added to the Netscaler plugin, and await a time when HA proxy has a stable release that includes SSL term. Darren On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed wrote: Hi, I have been working on adding SSL offload functionality to cloudstack and make it work for Netscaler. I have an initial design documented at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support and I would really love your feedback. The bug for this is https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . Thanks, -Syed
Re: [New Feature FS] SSL Offload Support for Cloudstack
On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote: > Technicality here, can we call the functionality SSL termination? > While technically we are "offloading" ssl from the VM, offloading > typically carries a connotation that its being done in hardware. So > we are really talking about SSL termination. +1 - completely agree. There's certainly the possibility of an *implementation* being true offloading, but I'd generalize to "termination" to account for a non-hardware offload of the crypto processing. > > Couple comments. I wouldn't want to assume anything about SSL based > on port numbers. So instead specify the protocol (http/https/ssl/tcp) > for the front and back side of the load balancer. Additionally, I'd > prefer the chain not be in the cert. When configuring some backends > you need the cert and chain separate. It would be easier if they were > stored that way. Otherwise you have to do logic of parsing all the > certs in the "keystore" and look for the one that matches the key. Also +1 to this. Cert chains may be optional, certainly, but should actually be separate from the actual cert in the configuration. The implementation may need to combine them into one document, but that's implementation specific. > > Otherwise, awesome feature. I'll tell you, from an impl perspective, > parsing and validating the SSL certs is a pain. I can probably find > some java code to help out here on this as I've done this before in > the past. Yes, this is a sorely needed feature. I'm happy to see this be added to the Netscaler plugin, and await a time when HA proxy has a stable release that includes SSL term. > > Darren > > On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed wrote: > > Hi, > > > > I have been working on adding SSL offload functionality to cloudstack and > > make it work for Netscaler. I have an initial design documented at > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support > > and I would really love your feedback. The bug for this is > > https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . > > > > Thanks, > > -Syed > > > > >
Re: [New Feature FS] SSL Offload Support for Cloudstack
Technicality here, can we call the functionality SSL termination? While technically we are "offloading" ssl from the VM, offloading typically carries a connotation that its being done in hardware. So we are really talking about SSL termination. Couple comments. I wouldn't want to assume anything about SSL based on port numbers. So instead specify the protocol (http/https/ssl/tcp) for the front and back side of the load balancer. Additionally, I'd prefer the chain not be in the cert. When configuring some backends you need the cert and chain separate. It would be easier if they were stored that way. Otherwise you have to do logic of parsing all the certs in the "keystore" and look for the one that matches the key. Otherwise, awesome feature. I'll tell you, from an impl perspective, parsing and validating the SSL certs is a pain. I can probably find some java code to help out here on this as I've done this before in the past. Darren On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed wrote: > Hi, > > I have been working on adding SSL offload functionality to cloudstack and > make it work for Netscaler. I have an initial design documented at > https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support > and I would really love your feedback. The bug for this is > https://issues.apache.org/jira/browse/CLOUDSTACK-4821 . > > Thanks, > -Syed > >
