Hi,

Following our talk on TLS work items split,
We need to decide how will we validate/extract certificates Barbican TLS 
containers.
As we agreed on IRC, the first priority should be certificates fetching.

TLS RST describes a new common module that will be used by LBaaS API and LBaaS 
drivers.
It's proposed front-end API is currently:
1. Ensuring Barbican TLS container existence (used by LBaaS API)
2. Validating Barbican TLS container (used by LBaaS API)
   This API will also "register" LBaaS as a container's consumer in Barbican's 
repository.
   POST request:
   http://admin-api/v1/containers/{container-uuid}/consumers
   {
    "type": "LBaaS",
    "URL": "https://lbaas.myurl.net/loadbalancers/<lbaas_loadbalancer_id>/"
   }

3. Extracting SubjectCommonName and SubjectAltName information
    from certificates' X509 (used by LBaaS front-end API)
   As for now, only dNSName (and optionally directoryName) types will be 
extracted from
    SubjectAltName sequence,

4. Fetching certificate's data from Barbican TLS container
    (used by provider/driver code)

5. Unregistering LBaaS as a consumer of the container when container is not
     used by any listener any more (used by LBaaS front-end API)

So this new module's front-end is used by LBaaS API/drivers and its back-end is 
facing Barbican API.
Please give your feedback on module API, should we merge 1 and 2?

I will be able to start working on the new module skeleton on Sunday morning. 
It will include API functions.

TLS implementation patch has a spot where container validation should happen: 
https://review.openstack.org/#/c/109035/3/neutron/db/loadbalancer/loadbalancer_dbv2.py
 line 
518<https://review.openstack.org/#/c/109035/3/neutron/db/loadbalancer/loadbalancer_dbv2.py%20line%20518>
After submitting the module skeleton I can make the TLS implementation patch to 
depend on that module patch and use its API.

As an alternative we might leave this job to drivers, if common module will be 
not implemented

What are your thoughts/suggestions/plans?

Thanks,
Evg

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to