Public bug reported: Currently Keystone doesn't honor the policy when dealing with trust creation. Indeed, it is harcoded that the trustor must be the authenticated user: [1]
In train release some patches were made to make the trust API honor the policy [2][3], but they purposely omit the trust creation part because "This does not enable system admins to create trusts. A trust can only be scoped to a project, so creating one is inherently a project-scoped action. If trusts later gain the ability to be scoped to the system or domains, we can add those scopes to the create_trust scope_types." I don't really get the point of this justification, as all the trust parameters can be specified in the API, including the project_id and the trustor_id (even the keystoneclient allow it). Why a user passing the policy shouldn't be able to create trusts on behalf of other users ? It can be very useful for orchestration use- cases, when operator want to automatize right delegation to allow PaaS services create ressources on behalf of a user in his project. [1] https://github.com/openstack/keystone/blob/master/keystone/api/trusts.py#L286 [2] https://bugs.launchpad.net/keystone/+bug/1818846 [3] https://bugs.launchpad.net/keystone/+bug/1818850 ** Affects: keystone Importance: Undecided Status: New ** Tags: trusts -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1954425 Title: Administrator can't create trusts on behalf of users Status in OpenStack Identity (keystone): New Bug description: Currently Keystone doesn't honor the policy when dealing with trust creation. Indeed, it is harcoded that the trustor must be the authenticated user: [1] In train release some patches were made to make the trust API honor the policy [2][3], but they purposely omit the trust creation part because "This does not enable system admins to create trusts. A trust can only be scoped to a project, so creating one is inherently a project-scoped action. If trusts later gain the ability to be scoped to the system or domains, we can add those scopes to the create_trust scope_types." I don't really get the point of this justification, as all the trust parameters can be specified in the API, including the project_id and the trustor_id (even the keystoneclient allow it). Why a user passing the policy shouldn't be able to create trusts on behalf of other users ? It can be very useful for orchestration use- cases, when operator want to automatize right delegation to allow PaaS services create ressources on behalf of a user in his project. [1] https://github.com/openstack/keystone/blob/master/keystone/api/trusts.py#L286 [2] https://bugs.launchpad.net/keystone/+bug/1818846 [3] https://bugs.launchpad.net/keystone/+bug/1818850 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1954425/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
