yahoo-eng-team team mailing list archive

[OpenStack Infra <1750669@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/667730
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=bbd77d0bf9dde57e5ca5d53f7214df85713b9f1e
Submitter: Zuul
Branch:    master

commit bbd77d0bf9dde57e5ca5d53f7214df85713b9f1e
Author: Lance Bragstad <lbragstad@xxxxxxxxx>
Date:   Wed Jun 26 20:54:22 2019 +0000

    Implement domain admin support for grants
    
    This commit goes through and updates grant policies to allow domain
    administrator to manager grants for their domains and projects within
    thier domain.
    
    Co-Authored-By: Colleen Murphy <colleen@xxxxxxxxxxx>
    
    Change-Id: I5f1839a3f8d23d17e449aa9f8710d70233ee8fcc
    Closes-Bug: 1805368
    Closes-Bug: 1750669


** Changed in: keystone
       Status: In Progress => Fix Released

-- 
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):
  Fix Released

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