yahoo-eng-team team mailing list archive

[Victor Coutellier <1954425@xxxxxxxxxxxxxxxxxx>]

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