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

[Vijay Kumar Venkatachalam]

>> 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:<email address hidden>]
Sent: 16 September 2015 00:32
To: OpenStack Development Mailing List (not for usage questions) <email address hidden>
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).

[Adam Harwell (adam-harwell)]

"Since the keystone session is marked for tenant “admin” lbaas is not able to get the tenant’s container/certificate."

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

Actually, that is incorrect. Neutron-LBaaS will contact Barbican as the admin tenant, and the ACLs set on the Barbican objects will allow the LBaaS tenant (NOT the user's tenant) access to the secrets.

You may actually be seeing an issue due to THIS bug, which I have a fix committed for already: https://bugs.launchpad.net/barbican/+bug/1519170

I am going to mark this as a duplicate for now.