Re: [openstack-dev] [Neutron][LBaaS] new common module for Barbican TLS containers interaction
This is not sufficient per our designs. For example the container Consumer
registration was supposed to be atomic and not handled in separate calls and I
don't like the inflexibility that we are just using tls_ids them selves for
every call. (For example We are forcing calls to the slow barbican APi for
pretty much every thing that is being done in the API and driver. I'm
discussing with adam a more appropriate set of stub modules.
Which brings another point up I want some separation between the Barican
interaction code and the low lever X509 parsing code. Hold on though I'm still
discussing/negotiating a proposal with Adam Harwell.
On Jul 27, 2014, at 7:21 AM, Evgeny Fedoruk evge...@radware.com wrote:
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
Re: [openstack-dev] [Neutron][LBaaS] new common module for Barbican TLS containers interaction
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
Re: [openstack-dev] [Neutron][LBaaS] new common module for Barbican TLS containers interaction
I'Just park a madule 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
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
