yahoo-eng-team team mailing list archive

[OpenStack Infra <1750660@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/624220
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=09663a01a4eda4332e55637a120019e1784b967e
Submitter: Zuul
Branch:    master

commit 09663a01a4eda4332e55637a120019e1784b967e
Author: Lance Bragstad <lbragstad@xxxxxxxxx>
Date:   Mon Dec 10 22:01:23 2018 +0000

    Implement domain admin functionality for projects
    
    This commit add explicit testing to show how users with the admin role
    on a domain can manage projects within their domain. It also modifies
    the default policies to account for this functionality. A subsequent
    patch will do the same for project users.
    
    Change-Id: I3e1cc44c4ed09ea0a4123ea13974b963c7335676
    Closes-Bug: 1750660
    Related-Bug: 1806762


** 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/1750660

Title:
  The v3 project 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 project API
  should behave with tokens from multiple scopes. WARNING: It also
  assumes that project tags are accessible to anyone with authorization
  to the project. If system administrators, or operators, intend to tag
  projects for administrative use (e.g. billing tags for accounting
  purposes), those tags will be accessible to users with access to the
  project:

  GET /v3/projects/{project_id}

  - Someone with a system role assignment that passes the check string should be able to get any project in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should be able to get any project within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should be able to get the project or any child project of the project they have a role assignment on (project-scoped)

  GET /v3/projects

  - Someone with a system role assignment that passes the check string should be able to list all projects in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should be able to list all projects within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should be able to list all child projects of the project they administer (project-scoped)?

  GET /v3/users/{user_id}/projects

  - Someone with a system role assignment that passes the check string should be able to list all projects for any user in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should be able to list projects for a user within the domain they administer, the response will only include projects in the domain they administer (domain-scoped)

  POST /v3/projects

  - Someone with a system role assignment that passes the check string should be able to create projects anywhere in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to create projects within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should only be able to create child projects of the project they administer (project-scoped)

  PATCH /v3/projects/{project_id}

  - Someone with a system role assignment that passes the check string should be able to update any project in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to update projects within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should only be able to update projects they administer or child projects of the ones they administer (project-scoped)?

  DELETE /v3/projects/{project_id}

  - Someone with a system role assignment that passes the check string should be able to delete any project in the deployment
  - Someone with a domain role assignment that passes the check string should only be able to delete a project within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should only be able to delete a child project of the project they administer (project-scoped)? 

  GET /v3/projects/{project_id}/tags

  - Someone with a system role assignment that passes the check string should be able to list tags for any project in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to list tags for a project within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should be able to list project tags associated to the project they have authorization on (project-scoped)

  GET /v3/projects/{project_id}/tags/{value}

  - Someone with a system role assignment that passes the check string should be able to get a project tag for any project in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to get a project tag for a project within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should only be able to get tags for a project, or a child project, they have authorization on.

  PUT /v3/projects/{project_id}/tags

  - Someone with a system role assignment that passes the check string should be able to up tags for any project in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to update tags for projects within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should only be able to update the tags for the project they administer, or children of that project (project-scoped)

  PUT /v3/projects/{project_id}/tags/{value}

  - Someone with a system role assignment that passes the check string should be able to tag any project in the deployment (system-scoped)
  - Someone with a domain role assignment that passes the check string should only be able to tag projects within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should only be able to tag the project they have authorization on or children of that project (project-scoped)

  DELETE /v3/projects/{project_id}/tags
  DELETE /v3/projects/{project_id}/tags/{value}
  - Someone with a system role assignment that passes the check string should be able to delete tags from any project in the deployment
  - Someone with a domain role assignment that passes the check string should only be able to delete tags from projects within the domain they administer (domain-scoped)
  - Someone with a project role assignment that passes the check string should only be able to delete tags from the project they have authorization on or children of that project (project-scoped)

  [0]
  https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/project.py

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