Comment 10 for bug 1592612

The problem happens in these three places:

https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/agent/agent_manager.py#L300
common/cert_manager/barbican_auth/barbican_acl.py
https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/common/keystone.py#L90

The first place is where the user's context is not handed down any more. The second place is where a hardwired admin context comes into play (i.e. the one returned by get_session()). The third link is the function that creates the hardwired context. As you can see from the attached stack trace (excerpted from neutron-lbaas.log), the path to that location is a bit long.

The LBaaS plugin is stuck with whatever credentials it is configured to use. Unless this configuration is changed from the default that's the admin user/admin tenant. For this to work sanely in a multi tenant environment, get_session() would have to return a session for the user who is currently talking to the Neutron API. This would render scary hacks (have the user explicitly grant access to their secret to the admin user) such as the one in the inital post on

https://bugs.launchpad.net/barbican/+bug/1627391

entirely unneccessary.

A fix along those lines is probably a bit longish, since the user context would have to be relayed through every driver in the neutron_lbaas.driver name space (I only checked for the haproxy driver that we used for testing, but I presume it's no different for the others). I tested this on stable/mitaka, but from a cursory glance at master the problem is the same in master: the Barbican key manager still uses get_session(), and get_session() still uses the static credentials from neutron.conf.

If the fix as outlined is acceptable, I can work on it, but I probably won't get to it until a little after the summit (of course I'd be happy to backport the fix to stable/newton).