[openstack-dev] [Neutron][LBaaS] new common module for Barbican TLS containers interaction

Carlos Garza carlos.garza at rackspace.com
Thu Jul 24 16:08:16 UTC 2014


Sorry I meant to say I'm pretty agreeable just park a stub module so I can populate it.
On Jul 24, 2014, at 11:06 AM, Carlos Garza <carlos.garza at rackspace.com>
 wrote:

> I'Just park a module with a stub call that I can populate with 
> pyasn1.
> On Jul 24, 2014, at 10:38 AM, Evgeny Fedoruk <EvgenyF at Radware.com>
> wrote:
> 
>> 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
>> 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list