Carlos,
The module skeleton, including API functions and their brief description, was
committed at https://review.openstack.org/#/c/109849/
checkContainerExistance -should be used by LBaaS API, I will
merge it into TLS implementation change.
- Throwing TLSContainerNotFound
exception
validateContainer -should be used LBaaS API instead of
checkContainerExistance if we will be able to implement it for Juno.
- Throwing TLSContainerNotFound or
TLSContainerInvalid exceptions
_getContainerAndRegisterConsumer - internal. Used by
checkContainerExistance and validateContainer. Getting container by posting
service as a container consumer.
unregisterContainerConsumer - should be used by LBaaS API when
container is not used for listeners anymore. I will implement it in TLS
implementation change. Also used by
- also used by checkContainerExistance
and validateContainer in order not to leave containers consumed in Barbican
before
- driver does the real consumer
registration with getCertificateX509 and/or extractCertificateHostNames
getCertificateX509 - should be used by specific vendor
driver. Getting container by posting service as a container consumer. Returns
certificate's X509
extractCertificateHostNames - should be used by specific vendor
driver. Getting certificate's X509 by using getCertificateX509 and returns SCN
and SAN names dict.
I will appreciate your opinion on this API.
Thanks,
Evg
-----Original Message-----
From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: Thursday, July 24, 2014 7:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] new common module for Barbican
TLS containers interaction
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.ga...@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 <evge...@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@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
