yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

Public bug reported:

Keystone implemented scope_types for oslo.policy RuleDefault objects in
the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API. This is documented in each patch with FIXMEs [0].

The following acceptance criteria describes how the v3 grant API should
behave with tokens from multiple scopes.

GET /target/{target_id}/actor/{actor_id}/roles/{role_id}

- Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)

GET /targets/{target_id}/actors/{actor_id}/roles

- Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)

PUT /target/{target_id}/actor/{actor_id}/roles/{role_id}

- Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)

DELETE /target/{target_id}/actor/{actor_id}/roles/{role_id}

- Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)

[0]
https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/grant.py#L62-L67

** Affects: keystone
     Importance: High
         Status: Triaged


** Tags: policy

** Changed in: keystone
       Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => High

** Description changed:

  Keystone implemented scope_types for oslo.policy RuleDefault objects in
  the Queens release. In order to take full advantage of scope_types,
  keystone is going to have to evolve policy enforcement checks in the
  user API. This is documented in each patch with FIXMEs [0].
  
  The following acceptance criteria describes how the v3 assignment API
  should behave with tokens from multiple scopes.
  
  GET /target/{target_id}/actor/{actor_id}/roles/{role_id}
  
  - Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)
  
  GET /targets/{target_id}/actors/{actor_id}/roles
  
  - Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)
  
  PUT /target/{target_id}/actor/{actor_id}/roles/{role_id}
  
  - Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)
  
  DELETE /target/{target_id}/actor/{actor_id}/roles/{role_id}
  
  - Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)
  
  [0]
- https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/project.py
+ https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/grant.py#L62-L67

** Summary changed:

- The v3 assignment API should account for different scopes
+ The v3 grant API should account for different scopes

** Description changed:

  Keystone implemented scope_types for oslo.policy RuleDefault objects in
  the Queens release. In order to take full advantage of scope_types,
  keystone is going to have to evolve policy enforcement checks in the
  user API. This is documented in each patch with FIXMEs [0].
  
- The following acceptance criteria describes how the v3 assignment API
- should behave with tokens from multiple scopes.
+ The following acceptance criteria describes how the v3 grant API should
+ behave with tokens from multiple scopes.
  
  GET /target/{target_id}/actor/{actor_id}/roles/{role_id}
  
  - Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)
  
  GET /targets/{target_id}/actors/{actor_id}/roles
  
  - Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)
  
  PUT /target/{target_id}/actor/{actor_id}/roles/{role_id}
  
  - Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)
  
  DELETE /target/{target_id}/actor/{actor_id}/roles/{role_id}
  
  - Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)
  
  [0]
  https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/grant.py#L62-L67

-- 
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/1750669

Title:
  The v3 grant API should account for different scopes

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  Keystone implemented scope_types for oslo.policy RuleDefault objects
  in the Queens release. In order to take full advantage of scope_types,
  keystone is going to have to evolve policy enforcement checks in the
  user API. This is documented in each patch with FIXMEs [0].

  The following acceptance criteria describes how the v3 grant API
  should behave with tokens from multiple scopes.

  GET /target/{target_id}/actor/{actor_id}/roles/{role_id}

  - Someone with a system role assignment that passes the check string should be able to check any grant in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to make checks against users, domains, and projects they administer (domain-scoped)

  GET /targets/{target_id}/actors/{actor_id}/roles

  - Someone with a system role assignment that passes the check string should be able to list all grants in the deployment, regardless of the target or actor (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to list grants against users and projects within the domain they administer (domain-scoped)

  PUT /target/{target_id}/actor/{actor_id}/roles/{role_id}

  - Someone with a system role assignment that passes the check string should be able to create grants, regardless of the actor or target (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to create grants with users and projects within the domain they administer (domain-scoped)

  DELETE /target/{target_id}/actor/{actor_id}/roles/{role_id}

  - Someone with a system role assignment that passes the check string should be able to remove grants regardless of the actor or target (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to remove grants from users and projects within the domain they administer (domain-scoped)

  [0]
  https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/grant.py#L62-L67

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1750669/+subscriptions