[openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency
Hi folks, In a current version of TLS capabilities RST certificate SubjectCommonName and SubjectAltName information is cached in a database. This may be not necessary and here is why: 1. TLS containers are immutable, meaning once a container was associated to a listener and was validated, it's not necessary to validate the container anymore. This is relevant for both, default container and containers used for SNI. 2. LBaaS front-end API can check if TLS containers ids were changed for a listener as part of an update operation. Validation of containers will be done for new containers only. This is stated in "Performance Impact" section of the RST, excepting the last statement that proposes persistency for SCN and SAN. 3. Any interaction with Barbican API for getting containers data will be performed via a common module API only. This module's API is mentioned in "SNI certificates list management" section of the RST. 4. In case when driver really needs to extract certificate information prior to the back-end system provisioning, it will do it via the common module API. 5. Back-end provisioning system may cache any certificate data, except private key, in case of a specific need of the vendor. IMO, There is no real need to store certificates data in Neutron database and manage its life cycle. Does anyone sees a reason why caching certificates' data in Neutron database is critical? Thank you, Evg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency
Evgeny-- The only reason I see for storing certificate information in Neutron (and not private key information-- just the certificate) is to aid in presenting UI information to the user. Especially GUI users don't care about a certificate's UUID, they care about which hostnames it's valid for. Yes, this can be loaded on the fly whenever public certificate information is accessed, but the perception was that it would be a significant performance increase to cache it. Stephen On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk wrote: > Hi folks, > > > > In a current version of TLS capabilities RST certificate SubjectCommonName > and SubjectAltName information is cached in a database. > > This may be not necessary and here is why: > > > > 1. TLS containers are immutable, meaning once a container was > associated to a listener and was validated, it’s not necessary to validate > the container anymore. > This is relevant for both, default container and containers used for SNI. > > 2. LBaaS front-end API can check if TLS containers ids were changed > for a listener as part of an update operation. Validation of containers > will be done for > new containers only. This is stated in “Performance Impact” section of the > RST, excepting the last statement that proposes persistency for SCN and SAN. > > 3. Any interaction with Barbican API for getting containers data > will be performed via a common module API only. This module’s API is > mentioned in > “SNI certificates list management” section of the RST. > > 4. In case when driver really needs to extract certificate > information prior to the back-end system provisioning, it will do it via > the common module API. > > 5. Back-end provisioning system may cache any certificate data, > except private key, in case of a specific need of the vendor. > > > > IMO, There is no real need to store certificates data in Neutron database > and manage its life cycle. > > Does anyone sees a reason why caching certificates’ data in Neutron > database is critical? > > > > Thank you, > > Evg > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency
Stephen, This will increase the complexity of the code since it will add managing the cache lifecycle in tandem with the barbican back end and the fact that containers may be shared by multiple listeners. At this stage, I think that it serves us all to keep the code at this stage as small and simple as possible. Let’s judge if presenting this information on the fly (ex: in the Web UI) becomes a performance issue and if it does, we can fix it then. -Sam. From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] Sent: Tuesday, July 22, 2014 3:43 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency Evgeny-- The only reason I see for storing certificate information in Neutron (and not private key information-- just the certificate) is to aid in presenting UI information to the user. Especially GUI users don't care about a certificate's UUID, they care about which hostnames it's valid for. Yes, this can be loaded on the fly whenever public certificate information is accessed, but the perception was that it would be a significant performance increase to cache it. Stephen On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk mailto:evge...@radware.com>> wrote: Hi folks, In a current version of TLS capabilities RST certificate SubjectCommonName and SubjectAltName information is cached in a database. This may be not necessary and here is why: 1. TLS containers are immutable, meaning once a container was associated to a listener and was validated, it’s not necessary to validate the container anymore. This is relevant for both, default container and containers used for SNI. 2. LBaaS front-end API can check if TLS containers ids were changed for a listener as part of an update operation. Validation of containers will be done for new containers only. This is stated in “Performance Impact” section of the RST, excepting the last statement that proposes persistency for SCN and SAN. 3. Any interaction with Barbican API for getting containers data will be performed via a common module API only. This module’s API is mentioned in “SNI certificates list management” section of the RST. 4. In case when driver really needs to extract certificate information prior to the back-end system provisioning, it will do it via the common module API. 5. Back-end provisioning system may cache any certificate data, except private key, in case of a specific need of the vendor. IMO, There is no real need to store certificates data in Neutron database and manage its life cycle. Does anyone sees a reason why caching certificates’ data in Neutron database is critical? Thank you, Evg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - certificates data persistency
I agree with Sam. We're under a strict timeline here and the simpler the code the faster it will be implemented and reviewed. Is there any strong reason why this caching can't wait until K if it decided it is really needed? Thanks, Brandon On Tue, 2014-07-22 at 11:01 +, Samuel Bercovici wrote: > Stephen, > > > > This will increase the complexity of the code since it will add > managing the cache lifecycle in tandem with the barbican back end and > the fact that containers may be shared by multiple listeners. > > At this stage, I think that it serves us all to keep the code at this > stage as small and simple as possible. > > > > Let’s judge if presenting this information on the fly (ex: in the Web > UI) becomes a performance issue and if it does, we can fix it then. > > > > -Sam. > > > > > > From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] > Sent: Tuesday, July 22, 2014 3:43 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - > certificates data persistency > > > > Evgeny-- > > > > > The only reason I see for storing certificate information in Neutron > (and not private key information-- just the certificate) is to aid in > presenting UI information to the user. Especially GUI users don't care > about a certificate's UUID, they care about which hostnames it's valid > for. Yes, this can be loaded on the fly whenever public certificate > information is accessed, but the perception was that it would be a > significant performance increase to cache it. > > > > > > Stephen > > > > > On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk > wrote: > > Hi folks, > > > > In a current version of TLS capabilities RST certificate > SubjectCommonName and SubjectAltName information is cached in a > database. > > This may be not necessary and here is why: > > > > 1. TLS containers are immutable, meaning once a container was > associated to a listener and was validated, it’s not necessary to > validate the container anymore. > This is relevant for both, default container and containers used for > SNI. > > 2. LBaaS front-end API can check if TLS containers ids were > changed for a listener as part of an update operation. Validation of > containers will be done for > new containers only. This is stated in “Performance Impact” section of > the RST, excepting the last statement that proposes persistency for > SCN and SAN. > > 3. Any interaction with Barbican API for getting containers data > will be performed via a common module API only. This module’s API is > mentioned in > “SNI certificates list management” section of the RST. > > 4. In case when driver really needs to extract certificate > information prior to the back-end system provisioning, it will do it > via the common module API. > > 5. Back-end provisioning system may cache any certificate data, > except private key, in case of a specific need of the vendor. > > > > IMO, There is no real need to store certificates data in Neutron > database and manage its life cycle. > > Does anyone sees a reason why caching certificates’ data in Neutron > database is critical? > > > > Thank you, > > Evg > > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > -- > Stephen Balukoff > Blue Box Group, LLC > (800)613-4305 x807 > > > ___ > 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] TLS capability - certificates data persistency
On Jul 20, 2014, at 6:32 AM, Evgeny Fedoruk wrote: > Hi folks, > > In a current version of TLS capabilities RST certificate SubjectCommonName > and SubjectAltName information is cached in a database. > This may be not necessary and here is why: > > 1. TLS containers are immutable, meaning once a container was > associated to a listener and was validated, it’s not necessary to validate > the container anymore. > This is relevant for both, default container and containers used for SNI. > 2. LBaaS front-end API can check if TLS containers ids were changed for > a listener as part of an update operation. Validation of containers will be > done for > new containers only. This is stated in “Performance Impact” section of the > RST, excepting the last statement that proposes persistency for SCN and SAN. > 3. Any interaction with Barbican API for getting containers data will > be performed via a common module API only. This module’s API is mentioned in > “SNI certificates list management” section of the RST. > 4. In case when driver really needs to extract certificate information > prior to the back-end system provisioning, it will do it via the common > module API. > 5. Back-end provisioning system may cache any certificate data, except > private key, in case of a specific need of the vendor. > > IMO, There is no real need to store certificates data in Neutron database and > manage its life cycle. > Does anyone sees a reason why caching certificates’ data in Neutron database > is critical? Its not so much caching the certificate. Lets just say when an lb change comes into the API that wants to add an X509 then we need to parse the subjectNames and SubjectAltNames from the previous X509s which aren't available to us so we must grab them all from barbican over the rest interface. Like I said in an earlier email its a balancing act between "Single Source of Truth" vs how much lag were willing to deal with. > Thank you, > Evg > > > ___ > 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] TLS capability - certificates data persistency
I'm willing to go with simpler code that gets us this feature faster, and re-evaluating whether storing some extra data on certificates locally makes significant performance gains later on. First we need to get it working, then we need to make it work fast. :) Stephen On Tue, Jul 22, 2014 at 4:04 PM, Carlos Garza wrote: > > On Jul 20, 2014, at 6:32 AM, Evgeny Fedoruk wrote: > > > Hi folks, > > > > In a current version of TLS capabilities RST certificate > SubjectCommonName and SubjectAltName information is cached in a database. > > This may be not necessary and here is why: > > > > 1. TLS containers are immutable, meaning once a container was > associated to a listener and was validated, it’s not necessary to validate > the container anymore. > > This is relevant for both, default container and containers used for SNI. > > 2. LBaaS front-end API can check if TLS containers ids were > changed for a listener as part of an update operation. Validation of > containers will be done for > > new containers only. This is stated in “Performance Impact” section of > the RST, excepting the last statement that proposes persistency for SCN and > SAN. > > 3. Any interaction with Barbican API for getting containers data > will be performed via a common module API only. This module’s API is > mentioned in > > “SNI certificates list management” section of the RST. > > 4. In case when driver really needs to extract certificate > information prior to the back-end system provisioning, it will do it via > the common module API. > > 5. Back-end provisioning system may cache any certificate data, > except private key, in case of a specific need of the vendor. > > > > IMO, There is no real need to store certificates data in Neutron > database and manage its life cycle. > > Does anyone sees a reason why caching certificates’ data in Neutron > database is critical? > > Its not so much caching the certificate. Lets just say when an lb > change comes into the API that wants to add an X509 then we need to parse > the subjectNames and SubjectAltNames from the previous X509s which aren't > available to us so we must grab them all from barbican over the rest > interface. Like I said in an earlier email its a balancing act between > "Single Source of Truth" vs how much lag were willing to deal with. > > > > > Thank you, > > Evg > > > > > > ___ > > 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 Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
