Description of problem: When creating a trust to impersonate a user, as admin, we get double blocked. This double-block doesn't allow operators to permit global admins the possiblity to impersonate users. Version-Release number of selected component (if applicable): python3-keystone-16.0.2-1.20200828063419.fb7d545.el8ost.noarch python3-keystoneauth1-3.17.3-0.20200714091827.7d7b956.el8ost.noarch python3-keystoneclient-3.21.0-0.20200225105518.79f150f.el8ost.noarch python3-keystonemiddleware-7.0.1-0.20200225105651.0a65b14.el8ost.noarch openstack-keystone-16.0.2-1.20200828063419.fb7d545.el8ost.noarch How reproducible: All the time Steps to Reproduce: 1. run a trust create (overcloud) [stack@undercloud-0 ~]$ openstack trust create --impersonate --project 412e7b23341c4a7dbce5d1aad3b23fd4 --role 146ce6560e2b4182950a7b88533e3c4f 17dab54e244f45fab1c0bc979bb10a1b 82db35a909714fe0b036adc18f49159a You are not authorized to perform the requested action: identity:create_trust. (HTTP 403) (Request-ID: req-e128a508-1346-43b4-b973-bada2e1b6ef0) 2. We are blocked by policies, so let's fix that: echo '"identity:create_trust": "role:admin or user_id:%(trust.trustor_user_id)s"' > /var/lib/config-data/puppet-generated/keystone/etc/keystone/policy.json && podman restart keystone 3. We now get blocked by the code: (overcloud) [stack@undercloud-0 ~]$ openstack trust create --impersonate --project 412e7b23341c4a7dbce5d1aad3b23fd4 --role 146ce6560e2b4182950a7b88533e3c4f 17dab54e244f45fab1c0bc979bb10a1b 82db35a909714fe0b036adc18f49159a You are not authorized to perform the requested action: The authenticated user should match the trustor. (HTTP 403) (Request-ID: req-af186bea-bade-4093-bb54-173e8bcf4c46) Actual results: We are blocked by the trust controller code [a]. [a] https://opendev.org/openstack/keystone/src/branch/master/keystone/api/trusts.py#L286-L288 Expected results: We might as well remove the create_trust policy because it's useless, or we remove this limitation to permit operators decide who can create trusts for who. Additional info: This bug was found because cinder doesn't allow the creation of volumes for tenants as admin. One of the proposed (and probably the most userfriendly) solution is to create a trust. This is discussed in Bug 1886253.
I tried to trace the original implementation of trusts [a] and it looks like the developer's intention was to permit admins to impersonate users [b]. There was a typo in this implementation and the fix, I believe, changed unexpectedly the behavior [c]. [a] https://opendev.org/openstack/keystone/commit/601eeb50b60a2e99041690fe19238202bc203503 [b] https://opendev.org/openstack/keystone/src/commit/601eeb50b60a2e99041690fe19238202bc203503/keystone/trust/controllers.py#L23-L27 [c] https://opendev.org/openstack/keystone/commit/4e996ec0975a28f5ceabf8d77cefe460f576cabc
I made this article [a] to describe how to generate a trust token. [a] https://access.redhat.com/solutions/5486601
This has been reported and fix upstream [0][1][2], at least as much as it can be given the trust contract. Trusts require the creator to be the trustor. Impersonation with trusts means the trustor (creator of the trust) is letting the trustee impersonate them. Trust code and policies, be default, do not support creating trusts for other people, even administrators. For what it's worth, most trust usage is being superceded by application credentials [3]. Does this help answer your question? [0] https://bugs.launchpad.net/keystone/+bug/1373599 [1] https://bugs.launchpad.net/keystone/+bug/1818846 [2] https://bugs.launchpad.net/keystone/+bug/1818850 [3] https://docs.openstack.org/keystone/latest/user/application_credentials.html
Lance, I can understand that upstream has chose to not let admins impersonate everyone even though I personally believe this should be the operator's place to decide, not us. I also understand the reason why these policies exists, even though there's another blocker, and it's to give operators the possibility to disable or restraint the trust system. Since this bug/rfe wasn't specifically requested by the customer, I'll go ahead and close it. We do have alternatives for the investigated use-case. Thanks Lance for all this information. I'll update the KCS. DVD