yahoo-eng-team team mailing list archive

[Vijay Kumar Venkatachalam <1497410@xxxxxxxxxxxxxxxxxx>]

Public bug reported:


>> This honestly hasn’t even been *fully* tested yet, but it SHOULD work.
It did not work. Please read on.
>> User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user (right now using whatever user-id we publish in our docs) to read their data.
I did perform the above step to give read access for the container and secrets to “admin”, but it did not work.

Root Cause
==========
The certmanager in lbaas which connects to barbican uses the keystone session gathered from
neutron_lbaas.common.keystone.get_session()
Since the keystone session is marked for tenant “admin” lbaas is not able to get the tenant’s container/certificate. 

Fix
==
The keystone session should have been generated with the tenant name set to the tenant name of the listener.


From: Adam Harwell [mailto:adam.harwell@xxxxxxxxxxxxx] 
Sent: 16 September 2015 00:32
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?

There is not really good documentation for this yet…
When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the user that is configured as the service-account in neutron.conf.
The user will hit the ACL API themselves to set up the ACLs on their own secrets/containers, we won’t do it for them. So, workflow is like:

•	User creates Secrets in Barbican.
•	User creates CertificateContainer in Barbican.
•	User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user (right now using whatever user-id we publish in our docs) to read their data.
•	User creates a LoadBalancer in Neutron-LBaaS.
•	LBaaS hits Barbican using its standard configured service-account to retrieve the Container/Secrets from the user’s Barbican account.
This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The question is whether right now in devstack the admin user is allowed to read all user secrets just because it is the admin user (which I think might be the case), in which case we won’t actually know if ACLs are working as intended (but I think we assume that Barbican has tested that feature and we can just rely on it working).

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1497410

Title:
  SSL Offload/Termination configuration not working for non-admin
  tenants

Status in neutron:
  New

Bug description:
  
  >> This honestly hasn’t even been *fully* tested yet, but it SHOULD work.
  It did not work. Please read on.
  >> User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user (right now using whatever user-id we publish in our docs) to read their data.
  I did perform the above step to give read access for the container and secrets to “admin”, but it did not work.

  Root Cause
  ==========
  The certmanager in lbaas which connects to barbican uses the keystone session gathered from
  neutron_lbaas.common.keystone.get_session()
  Since the keystone session is marked for tenant “admin” lbaas is not able to get the tenant’s container/certificate. 

  Fix
  ==
  The keystone session should have been generated with the tenant name set to the tenant name of the listener.

  
  From: Adam Harwell [mailto:adam.harwell@xxxxxxxxxxxxx] 
  Sent: 16 September 2015 00:32
  To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@xxxxxxxxxxxxxxxxxxx>
  Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant?

  There is not really good documentation for this yet…
  When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the user that is configured as the service-account in neutron.conf.
  The user will hit the ACL API themselves to set up the ACLs on their own secrets/containers, we won’t do it for them. So, workflow is like:

  •	User creates Secrets in Barbican.
  •	User creates CertificateContainer in Barbican.
  •	User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user (right now using whatever user-id we publish in our docs) to read their data.
  •	User creates a LoadBalancer in Neutron-LBaaS.
  •	LBaaS hits Barbican using its standard configured service-account to retrieve the Container/Secrets from the user’s Barbican account.
  This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The question is whether right now in devstack the admin user is allowed to read all user secrets just because it is the admin user (which I think might be the case), in which case we won’t actually know if ACLs are working as intended (but I think we assume that Barbican has tested that feature and we can just rely on it working).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1497410/+subscriptions