Open Stack

On Jul 20, 2014, at 6:32 AM, Evgeny Fedoruk <EvgenyF at 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?

    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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev