Comment 12 for bug 1592612

Sorry, I missed the comment and thus the IRC meeting. I had a look at the log[0] and I'd like to clarify some things, I probably didn't get across all that well:

I'm not proposing to save the user context. I propose to use it in neutron_lbaaas. If a user creates a secret container, and that same user then creates a load balancer, neutron_lbaas can use that user's authenticated context passed from the Neutron API/middleware to neutron_lbaas (rather than the admin user's context) to retrieve the container in question.

That being said, after I've read the log I realized that's not really feasible. It does not allow this kind of access the container long after the authenticated session's token has expired:

  20:18:12 <sbalukoff> So, part of the problem here lies in the fact that LBaaS / Octavia may need
  to access the secrets at a time when the user isn't actively deploying a load balancer that
  requires a secret. That is to say, in a fail-over situation, LBaaS / Octavia will need to access
  the secret.

So there is in fact a need to have some sort of long-term access to the container. That can be done without ACLs, though. The "standard" (as in: multiple projects use it) mechanism for this is Keystone trusts. Namely, Heat (see [1] for an in-depth description) and Magnum use these for deferred operations. They're not the ideal least-privilege solution (in my book, that ideal would be a token that only allows access to _one_ specific resource), but they are far more restrictive than granting the Neutron service user access to any or all of a user's secrets.

As for further discussion at the Summit: I'll be there from Tuesday morning until early Friday afternoon, and I'd be happy to meet up for further discussion. I'll give some thought to implementing this in a backwards compatible manner in the mean time.

[0] http://eavesdrop.openstack.org/meetings/barbican/2016/barbican.2016-10-10-20.00.log.txt
[1] http://hardysteven.blogspot.de/2014/04/heat-auth-model-updates-part-1-trusts.html