"admin"-ness not properly scoped

[Gabriel Hurley]

Fact: Keystone's rbac model grants roles to users on specific tenants, and post-keystone redux, there are no longer "global" roles.

Problem: Granting a user an "admin" role on ANY tenant grants them unlimited "admin"-ness throughout the system because there is no differentiation between a scoped "admin"-ness and a global "admin"-ness.

I don't have a specific solution to advocate, but being an admin on *any* tenant simply *cannot* allow you to administer all of keystone.

Steps to reproduce (from Horizon, though you could do this with the CLI, too):

1. User A (existing admin) creates Project B and User B.
2. User A adds User B to Project B with the admin role on Project B.
3. User B logs in and now has unlimited admin rights not only to view things in the dashboard, but to take actions like creating new projects and users, managing existing projects and users, etc.

Note: See changes ongoing under https://bugs.launchpad.net/neutron/+bug/1602081 which is required before policy changes can enforce.

[Dolph Mathews (dolph)]

To clarify steps 1 & 2, I read this as two *different* relationships being created between User B and Project B.

First, User B is created with a default tenant of Project B. <-- This behaves as expected.
Second, User B is explicitly granted the admin role on Project B. <-- This take effect globally, regardless.

In terms of the keystone CLI, this looks like:

    keystone tenant-create --name=project-b
    keystone user-create --name=user-b --pass=secret --tenant_id=<tenant id of project b>
    keystone user-role-add --user=<user id of user b> --role=<role id of admin role> --tenant_id=<tenant id of project b>

After creating User B, I then confirmed the bug by authenticating as User B for Project B, and then successfully listing all users and tenants in the system, and then subsequently deleting User A and Project A.

[Vish Ishaya (vishvananda)]

Perhaps the issue here is that we need a way to define adminness that extends beyond the tenant level.

[Gabriel Hurley (gabriel-hurley)]

@vish: that's my thinking as well... it used to be "global" roles vs. "scoped" roles prior to the keystone redux. I missed the discussion that lead to removing that capacity (which would also be useful for the "service" users that got created), but I'm concerned that any such discussion may be too late for Essex now. :-/

One way or the other, there are definitely system-level capabilities which go beyond specific tenants that aren't currently being accounted for.

[termie (termie)]

Keystone only has two levels of access, admin and public, there are no actions that are scoped to tenants or users (as we discussed before, for example, a user cannot change her own password). Ergo, if you are giving somebody a keystone admin role, that means they can do literally anything in keystone.

There are a variety of things that can be done to add more granular permissions, but right now this "bug" is invalid and is just a mis-expectation. Makes a perfectly fine feature request though: the feature request would be titled "add more granular access control to keystone" and would include a list of proposed requirements to perform certain kinds of actions, one example might be a tenant_admin that can do anything on the current tenant.

[Gabriel Hurley (gabriel-hurley)]

If this is a mis-expectation than it's a bug on a completely misleading interface. If a role is assigned *on a tenant* the very reasonable expectation is that it has some connection *to that tenant*.

I fail to see the purpose of connecting roles and tenants if they are not scoped.

[Thierry Carrez (ttx)]

Sounds like a Keystone question, before becoming a Nova-specific issue. removing "nova" from the affected projects, feel free to add it back if anything needs to be done on Nova side.

[Joseph Heck (heckj)]

I believe this bug will be resolved with the proposed V3 API and the domains support there. Please review at https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit?pli=1

[Gabriel Hurley (gabriel-hurley)]

With all due apologies, Thierry, this is absolutely a bug in the current Nova codebase. They have inconsistently implemented the scoping of objects as-is. Half the Nova resource APIs respect admin vs. non-admin tokens, half don't. That in and of itself has to be fixed independently of Keystone's future guidelines.

Keystone's role in this is to shape what objects should be authorized, but it does not fix an incomplete implemntation as it stands currently.

[Gabriel Hurley (gabriel-hurley)]

With my Horizon hat on, now, the current proposal on that table is this:

Add a splash message in the header that displays any time an "admin" user is in the Project Dashboard with a cautionary message indicating they are acting as an admin, and that there are several actions which they should be aware of as potentially causing significant problems. The splash message will be short, but will link to a longer documentation of the known problems and their origins.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/8588

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/8588
Committed: http://github.com/openstack/horizon/commit/41307a354581f2e2b50dfa6a7d7b88cac9f642e1
Submitter: Jenkins
Branch: master

commit 41307a354581f2e2b50dfa6a7d7b88cac9f642e1
Author: Gabriel Hurley <email address hidden>
Date: Thu Jun 14 17:50:42 2012 -0700

    Adds warning banner for admin users in project dash.

    This is a bandaid until the underlying bugs in Nova get fixed.

    Fixes bug 968696.

    Change-Id: I735453482023dabc28069a4a8796aa43001f1891

[Vish Ishaya (vishvananda)]

FYI, this is fixed for volumes snapshots and keypairs now.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/essex
Review: https://review.openstack.org/11711

[Dolph Mathews (dolph)]

This has been a well known and often discussed issue in keystone ... but it's still not totally resolved. I'm hoping that we've now laid sufficient groundwork (domains, policy, etc) to properly address this soon.

[Bryan Murray (bryan-murray)]

In general, it is desirable to have different scopes of admins. A cloud admin is needed to create and manage domains. A domain admin is needed to create and manage users and projects for a domain. A project admin is required to manage the resources created by members of a project.

The solution is likely to be a combination of changes to the policy file and establishing conventions for the "home" domain and project for different scopes of admin.

[Adam Young (ayoung)]

Commit c7a5c6cf27a80ca50db9f1a1a74e8795eeefd9d1 is the start of addressing the issue: a deployment can replace the default policy file with one that is more correctly specified. However, just changing this outright will break most/all curent deployments.

[Arvind Tiwari (arvind-tiwari)]

My suggestion to fix this issue

The biggest problem here is “roles name is global and keystone can no differentiate foo(Admin) vs bar(Admin)“ that is why Admin on a project become is admin on keystone resources (prject,users, group….) too.

This issue is mainly due to insufficiency of role data model which is nothing but just a name and there is no way we can define same role name for different services.

Solution:
======
1. Keystone should register itself in keystone along with other services and has given some name unique service_id. (e.g. keystone or identity=100 , NOVA=110 and Swift=120) (chicken and egg problem but can be done through system bootstrap)

2. Role definition should be scoped to a service_id, so that every service can create their own role.(e.g. Admin(100), Admin(110) and Admin(120)).

3. Role definition should have some info (may be a flag like for_non_project_use_only=true) to guide role assignment logic, so that certain role can/can’t be assigned to a project. (e.g. Admin(100,true), Admin(110,false) and Admin(120,false))

4. There should be validation in role assignment based on role definition’s for_non_project_use_only filed, so that non_project roles can’t be assigned to a project.

5. Based on scoping (domain/project) Token response should return role list with service_id (e.g. [Admin(110), Admin(120)])

6. Service scoped Auth (token) request should also be provided.

7. For any keystone API calls, internal user credential (which is used to validate against policy) should have role with service_id (e.g. [Admin(110), Admin(120)])

8. Keystone policy which considers role should also add “service_id” in policy (e.g. "identity:create_project": ["role:Admin and service_id:%(100)s"])
  8.1 Note: target.service_id should be always 100 because we are operating on identity API, that means the target is controlled by identity(100) service.
  8.2 For identity:create_project API call if user have “Admin(110)” (admin role scoped to a project) wd not satisfy "role:Admin and service_id:%(100)s" policy

[Arvind Tiwari (arvind-tiwari)]

I mean "role definition" when I say "role name" in above comment

[David Chadwick (d-w-chadwick)]

It seems as if we have a number of problems here:

1. Creating a role is partly implicit rather than fully explicit.
Creating a role should comprise two steps, namely:
i) Assigning permissions to the role
ii) Assigning users to the role
But in Keystone step i) is missing (at least when the admin role is created). The permissions seem to be predefined (ie. implicit). This is missing functionality in my opinion. Termie is partially correct in his posting of 2012-03-30 when he says "add more granular access control to keystone". I would go further, and say "allow administrators to set access control permissions for roles in Keystone"

2. Roles have to be linked to tenants on creation.
This is a completely spurious linking and is not needed. It serves no functional purpose as I am aware and only complicates the model for no good reason. If you want to limit the permissions of a role to only take effect for a tenant (project) then add a new parameter to a role on creation, called its scope, and add the tenant (project) in the scope field.

3. Role names are global and taken from the same flat namespace.
Role names need to become hierarchical so that different entities can define their own roles, and the name of the role is concatenated with the name of the creating entity so that we still have global role names. Use the DNS as an exemplar for how roles should be named.

[Dolph Mathews (dolph)]

David,

1 i) is based on policy.json, and is effectively decentralized throughout openstack (although keystone has it's own policy.json), which I believe satisfies termie's request.

2) Either way you're linking them to tenants/projects -- what does the alternative method buy you?

[David Chadwick (d-w-chadwick)]

Hi Dolph

so 1 i) now fixed through Keystone's policy file. That is good

2). Roles do not need to be linked to tenants. The keystone admin role should not be as it should apply to all tenants. The scoping mechanism that we are discussing on the list will optionally scope a role to a domain, project or service at the decision of the creator. So this provides greater flexibility and is not mandatory, unlike the current mechanism which requires a project to be linked to the role on creation.

[Dolph Mathews (dolph)]

David,

2) I think the shortest path to resolve this issue is not to fundamentally change roles, but to use the current roles design and approach to assignments and simply extend them to assignments upon services:

  https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens

I believe that adding the scoping behavior of roles that you're describing would be compatible with the above, but I'd like to save that discussion for another context.

[Arvind Tiwari (arvind-tiwari)]

Dolph,

2) I my opinion resources (services) should be abstracted from assignments otherwise your assignments data model will be impacted whenever we invent new resource. e.g. there was a proposal for resource groups and accommodate role assignment on resource groups by changing the assignment data model.

[Arvind Tiwari (arvind-tiwari)]

To further support "resources (services) should be abstracted from assignments" statement. Suppose we want to segregate admin-ness at endpoint level. (e.g. userA should have admin role on East but not West Nova endpoints). We can extend assignment to model this also but for how long.

[Florent Flament (florentflament)]

Cathing up on this bug, if I understand well, the initial issue was that there wasn't a way to grant admin-ness on a project without granting total control over all Openstack resources.

I think that this can now be achieved by defining appropriate roles and policy rules.

For instance we can create a `project_admin` role that only allows a project admin to grant the `Member` role on his own project to other users, with the following rule:
"identity:create_grant": "role:project_admin and project_id:%(target.project.id)s and 'Member':%(target.role.name)s"

Although the last condition needs the following patch, allowing to check context variables against constants during the policy enforcement phase : https://review.openstack.org/#/c/68176/

[Dolph Mathews (dolph)]

Florent: "project_admin" is a completely viable workaround today, but the issue remains that "admin" is still relatively magical compared to the way other roles are handled, as it does not respect the scope to which it's assigned.

[Jason (jason-ob)]

I think there really needs to be at least three or four concepts here OOB: (I say 3 or 4 since 3 could just be a configuration of 2)

1) Tenant Admin - specific to that tenant only
2) Multi-tenant Admin - across a specific set of tenants
3) Global-Tenant Admin - Admin access to all tenants but not "system" actions (changing endpoints, making policy changes, etc.)
4) Global "System" Admin - God

Even in file-system ACLs, there is adistinction between RWX and RWX + modify ACL

I also think it would be a common use case to want to manage multiple tenants at once without having to re-authenticate to each one in turn, but that's a battle I'm sure I won't win.

[Song Li (lisong-cruise)]

Admin of one tenant can also create networks, routers and so on in other tenants, and take other actions. It might be a big risk for the security.
So I think it also affect the Neutron.

[Eugene Nikanorov (enikanorov)]

Please provide more information on what you suggest for neutron with respect to this bug.

Neutron doesn't support RBAC at the moment, but it will not be added in the scope of one bugfix, i guess.

[Song Li (lisong-cruise)]

@Eugene Nikanorov (enikanorov)
Hi Eugene, Thanks for your reply.

Indeed, I just want to make sure that whether it will be safer that the admin of the tenant can only manage the network in their own tenants. Because, there is an issue that someone thought that HEAT should allow admin to create Networks in other tenants by HEAT. And we found the issue you are working on.

So we just want to make sure the trend that "the admin scope will be limited in future", or make sure "Heat did not allow admin to create networks in other tenant will block any important Neutron functional case".
Could you help to give me some advise?

And I have one question:
If the keystone fix the issue, admin will cannot create Networks in other tenant. Is that true?

[Adam Young (ayoung)]

IN order to close out this bug, all of the places that policy is enforced need to be scoped. This is, I think possible today, with the4 exception of "deleting resources for a deleted project" but a patch has been proposed that should address that:

https://review.openstack.org/#/c/203852/

The other places where global admin is required today are on calls like "create cells" in Nova, where the Cell abstraction is not scoped to any project. There is an admin project specified in the authtoken section of the config file, and that can be used to scope anything that is endpoint-level instead of end-user-project level.

Making this happen will require rewriting the policy files for each of the services, to include Keystone, to make sure that the "admin" role is not used anywhere without also checking for a project scope. As such, this bug affects each of the projects equally, but it is not a Keystone specific issue to solve.

[Adam Young (ayoung)]

Note that fixing the scoping is dependent on

https://bugs.launchpad.net/keystone/+bug/1476264

As that seems to be the only reason we currently need a global admin.

For other operations that do not have a scope on the object/API to check, policy should default to using the admin tenant configured when setting up the server in the authtoken section of the config file.

domain =default,
project = admin

That can be overridden in a production deployment, but matches what devstack currently does.

[Brent Roskos (broskos)]

I'd like to add a few lines to cinder to allow other fields to be considered when determining admin. Currently this is only role. Though not ideal, a combination of role/user/project and or domain can be used to satisfy the is_admin functionality currently used.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/213501

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/213501
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=9840721b51671296816d681dbd4b9afe221f68b4
Submitter: Jenkins
Branch: master

commit 9840721b51671296816d681dbd4b9afe221f68b4
Author: Brent Roskos <email address hidden>
Date: Sun Aug 16 08:41:48 2015 -0400

    adds user_id to check_is_admin

    A small tactical update to allow cinder to consider user_id
    when checking for admin.

    This is needed in the field until the larger changes around
    admin scoping are completed. Checking for role only is not
    sufficient in a multi-domain configuration.

    juno-backport-potential
    kilo-backport-potential

    closes-bug: 968696

    Change-Id: I0cb99186bd833c4c32964490c4bc6da9ad42d320

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/217695

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/217728

[Adam Young (ayoung)]

Proposed solution:

1. Add a config value ADMIN_PROJECT_ID
2. In token creation, if ADMIN_PROJECT_ID is not None: only add the admin role to the token if the id of the scoped project == ADMIN_PROJECT_ID

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/233480

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/605851
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=1d32de5fe9c8465e2a70bf75dba7bdfeefa80ec9
Submitter: Zuul
Branch: master

commit 1d32de5fe9c8465e2a70bf75dba7bdfeefa80ec9
Author: Lance Bragstad <email address hidden>
Date: Thu Sep 27 19:12:20 2018 +0000

    Allow domain users to access the GET domain API

    This change updates the policy for identity:get_domains to allow
    users with role assignments on a domain to fetch the domain. As long
    as they call the API with a domain scoped token, they should be
    authorized to retrieve the domain. Subsequent patches will do the
    same for project users.

    Change-Id: I83a9b8af775580d36a1141be55e9c1cc283a75b6
    Partial-Bug: 1794864
    Partial-Bug: 968696

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/605871
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=2c8f81af62cd03601fca259647991d5dd7f8d560
Submitter: Zuul
Branch: master

commit 2c8f81af62cd03601fca259647991d5dd7f8d560
Author: Lance Bragstad <email address hidden>
Date: Thu Sep 27 21:51:12 2018 +0000

    Allow project users to retrieve domains

    This commit adds thorough testing to make sure users who have a role
    on a project can use project-scoped tokens to call GET
    /v3/domain/{domain_id} for the domain own their project. These users
    are not allowed to access domains that they don't have any
    authorization via project role assignments.

    This ensures the domains API is tested with these cases and makes the
    domains API more self-serviceable for users that are not
    administrators.

    Change-Id: Ifc100a7a235140fbd07cbafe80983d3c2f17a7dc
    Closes-Bug: 1794864
    Related-Bug: 968696

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/605485
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=40d3458fcb29df1daefce9455d1778e800cac378
Submitter: Zuul
Branch: master

commit 40d3458fcb29df1daefce9455d1778e800cac378
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 19:39:56 2018 +0000

    Implement system reader role for users

    This commit introduces the system reader role to the users API, making
    it easier for administrators to delegate subsets of responsibilities
    to the API by default. This commit also maintains the ability for
    any user to be able to fetch their own user reference.

    Subsequent patches will incorporate:

      - system member test coverage
      - system admin functionality
      - domain reader functionality
      - domain member test coverage
      - domain admin functionality
      - project user test coverage

    Change-Id: I9c362e515772540dfa93d05781d955009b9a154d
    Partial-Bug: 1805406
    Partial-Bug: 1748027
    Partial-Bug: 968696

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/623317
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=4f724f2d9387dc83148dada41a0f9acb294026c2
Submitter: Zuul
Branch: master

commit 4f724f2d9387dc83148dada41a0f9acb294026c2
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 19:48:36 2018 +0000

    Implement system member role user test coverage

    This commit introduces explicit test coverage for system members,
    making sure they are allowed to do readable and not writable user
    operations.

    Subsequent patches will incorporate:

      - system admin functionality
      - domain reader functionality
      - domain member test coverage
      - domain admin functionality
      - project user test coverage

    Change-Id: Ibc837225154ba7bcd2f93938565b41ff0e8f4803
    Partial-Bug: 1805406
    Partial-Bug: 1748027
    Partial-Bug: 968696

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/623318
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=29fb7ae3952138ec05fd2434fe9cf5eccc8205f0
Submitter: Zuul
Branch: master

commit 29fb7ae3952138ec05fd2434fe9cf5eccc8205f0
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 19:59:36 2018 +0000

    Implement system admin role in users API

    This commit introduces the system admin role to the users API,
    making it consistent with other system-admin policy definitions.

    Subsequent patches will build on this work to expose more
    functionality to domain and project users:

     - domain reader functionality
     - domain member test coverage
     - domain admin functionality
     - project user test coverage

    Change-Id: I19bf5a562401100d9208f98515ce596f7ca20185
    Closes-Bug: 1805406
    Partial-Bug: 1748027
    Partial-Bug: 968696

[OpenStack Infra (hudson-openstack)]

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

commit feb0d58df4ce4531d3e381c24385a531d164ee2a
Author: Lance Bragstad <email address hidden>
Date: Mon Dec 17 22:40:04 2018 +0000

    Implement system reader role for groups

    This commit introduces the system reader role to the group API, making
    it easier for administrators to delegate subsets of responsibilities
    to the API by default. This commit also maintains the ability for
    any user to be able to fetch their own group memberships, which
    encapsulates a bunch of tests for what regular project users can do
    with groups.

    Subsequent patches will incorporate:

      - system member test coverage
      - system admin functionality
      - domain reader functionality
      - domain member test coverage
      - domain admin functionality

    Change-Id: I24ff27da79bb01322e05c6d8cd37f02693fd5b9f
    Related-Bug: 1805369
    Related-Bug: 1808859
    Related-Bug: 968696

[OpenStack Infra (hudson-openstack)]

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

commit f66070995d4f0f76f68fde29fa2d5a4e90f26ce8
Author: Lance Bragstad <email address hidden>
Date: Mon Dec 17 22:43:21 2018 +0000

    Implement system member test coverage for groups

    This commit introduces explicity test coverage for system members,
    making sure they are allowed to perform readable and not writable
    group operations.

    Subsequent patches will incorporate:

      - system admin functionality
      - domain reader functionality
      - domain member test coverage
      - domain admin functionality

    Change-Id: Ie22a18ac7b243089509001fda930474f55e29d3f
    Related-Bug: 1805369
    Related-Bug: 1808859
    Related-Bug: 968696

[OpenStack Infra (hudson-openstack)]

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

commit f62f73c548d7a1cb4fe557e457a49d77322968c4
Author: Lance Bragstad <email address hidden>
Date: Mon Dec 17 23:05:08 2018 +0000

    Implement system admin role in groups API

    The commit introduces the system admin role to the group API, making
    it consistent with other system-admin policy definitions.

    Subsequent patches will incorporate:

      - domain reader functionality
      - domain member test coverage
      - domain admin functionality

    Change-Id: Ib0ff05396bed2bfefefa712491aeb0b9b5f2c1d0
    Related-Bug: 968696
    Related-Bug: 1808859
    Closes-Bug: 1805369

[OpenStack Infra (hudson-openstack)]

Change abandoned by Lance Bragstad (<email address hidden>) on branch: master
Review: https://review.openstack.org/624221
Reason: Abandoning this patch since most of the work done here was pulled forward to the system-reader patch.

https://review.openstack.org/#/c/624215/5

[OpenStack Infra (hudson-openstack)]

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

commit bc217b316e13942cb7f4fc742be988d27bd32aa2
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 20:21:28 2018 +0000

    Implement domain reader functionality for user API

    This commit adds explicit testing for how users with the reader role
    on a domain should interact with users both inside and outside of
    the domain they have authroization on.

    Subsequent patches will continue to build on this by incorporating:

     - domain member test coverage
     - domain admin functionality
     - project user test coverage

    Change-Id: I09f520aaed9560541d183ac83a1a7241d8d0d2f1
    Partial-Bug: 1748027
    Partial-Bug: 968696

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/623320
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=9ca599e50610fadc60e1b05c1af37044916575c5
Submitter: Zuul
Branch: master

commit 9ca599e50610fadc60e1b05c1af37044916575c5
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 20:31:08 2018 +0000

    Implement domain member functionality for user API

    This commit adds explicit testing for how users with the member role
    on a domain should interact with users both inside and outside of
    the domain they have authroization on.

    Subsequent patches will continue to build on this by incorporating:

     - domain admin functionality
     - project user test coverage

    Change-Id: I2a75f49e953c0c6fbe2de6da7b40faaa208f953d
    Partial-Bug: 1748027
    Partial-Bug: 968696

[OpenStack Infra (hudson-openstack)]

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

commit cf1ce4eb36393cedadb2de2aeba8140c65e09775
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 20:50:28 2018 +0000

    Implement domain admin functionality for user API

    This commit add explicit testing to show how users with the admin role
    on a domain can manage users within thier domain. It also modifies the
    default policies to account for this functionality. A subsequent patch
    will do the same for project users.

    Change-Id: I3899e07b857e213f85384ed9c9e4add199290a49
    Partial-Bug: 1748027
    Partial-Bug: 968696

[OpenStack Infra (hudson-openstack)]

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

commit f9e07a940dc6d197709f5a66c8e4ff203d388da1
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 21:01:14 2018 +0000

    Add explicit testing for project users and the user API

    This commit wraps up the user API policy refactor by adding explicit
    testing for how project users are expected to behave with the user
    API. A subsequent patch set will remove the now obsolete user policies
    in policy.v3cloudsample.json.

    Change-Id: Ic7b0839ac70439aa0311a98c6b7b5688a7e2dcf7
    Closes-Bug: 1748027
    Related-Bug: 968696

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.openstack.org/647548

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.openstack.org/647549

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.openstack.org/647550

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/stein
Review: https://review.openstack.org/647551

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/647737

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/647548
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=69868c6bfdeca737ea7c48057beb3b657e14091b
Submitter: Zuul
Branch: stable/stein

commit 69868c6bfdeca737ea7c48057beb3b657e14091b
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 20:21:28 2018 +0000

    Implement domain reader functionality for user API

    This commit adds explicit testing for how users with the reader role
    on a domain should interact with users both inside and outside of
    the domain they have authroization on.

    Subsequent patches will continue to build on this by incorporating:

     - domain member test coverage
     - domain admin functionality
     - project user test coverage

    Change-Id: I09f520aaed9560541d183ac83a1a7241d8d0d2f1
    Partial-Bug: 1748027
    Partial-Bug: 968696
    (cherry picked from commit bc217b316e13942cb7f4fc742be988d27bd32aa2)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/647549
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=dd6da4cd459d330dc2feb017c470da321604784a
Submitter: Zuul
Branch: stable/stein

commit dd6da4cd459d330dc2feb017c470da321604784a
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 20:31:08 2018 +0000

    Implement domain member functionality for user API

    This commit adds explicit testing for how users with the member role
    on a domain should interact with users both inside and outside of
    the domain they have authroization on.

    Subsequent patches will continue to build on this by incorporating:

     - domain admin functionality
     - project user test coverage

    Change-Id: I2a75f49e953c0c6fbe2de6da7b40faaa208f953d
    Partial-Bug: 1748027
    Partial-Bug: 968696
    (cherry picked from commit 9ca599e50610fadc60e1b05c1af37044916575c5)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/647550
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=a5fbec6a091afe28d04bfdb331a56aa14d6e7ff3
Submitter: Zuul
Branch: stable/stein

commit a5fbec6a091afe28d04bfdb331a56aa14d6e7ff3
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 20:50:28 2018 +0000

    Implement domain admin functionality for user API

    This commit add explicit testing to show how users with the admin role
    on a domain can manage users within thier domain. It also modifies the
    default policies to account for this functionality. A subsequent patch
    will do the same for project users.

    Change-Id: I3899e07b857e213f85384ed9c9e4add199290a49
    Partial-Bug: 1748027
    Partial-Bug: 968696
    (cherry picked from commit cf1ce4eb36393cedadb2de2aeba8140c65e09775)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/647551
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=8da74c1756d5c8ce7a33cb3f18d45d2d7c7bc63a
Submitter: Zuul
Branch: stable/stein

commit 8da74c1756d5c8ce7a33cb3f18d45d2d7c7bc63a
Author: Lance Bragstad <email address hidden>
Date: Thu Dec 6 21:01:14 2018 +0000

    Add explicit testing for project users and the user API

    This commit wraps up the user API policy refactor by adding explicit
    testing for how project users are expected to behave with the user
    API. A subsequent patch set will remove the now obsolete user policies
    in policy.v3cloudsample.json.

    Change-Id: Ic7b0839ac70439aa0311a98c6b7b5688a7e2dcf7
    Closes-Bug: 1748027
    Related-Bug: 968696
    (cherry picked from commit f9e07a940dc6d197709f5a66c8e4ff203d388da1)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/647737
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=60e0f00326ee41968730f9d72fc77cab26af3d9f
Submitter: Zuul
Branch: master

commit 60e0f00326ee41968730f9d72fc77cab26af3d9f
Author: Colleen Murphy <email address hidden>
Date: Tue Mar 26 14:40:00 2019 +0100

    Add release prelude about changing policies

    This change adds a prelude to the release notes to inform operators
    about the changing policy defaults and how to handle them, since these
    are going to be quite a big change and cause a lot of log warnings.

    Change-Id: If067866daa8abbe41027018c260a3e01bddbb92f
    Related-bug: #968696

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/stein
Review: https://review.openstack.org/648819

[OpenStack Infra (hudson-openstack)]

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

commit be452fee80fabe252b2dae3be76c1d46fdd857e4
Author: Colleen Murphy <email address hidden>
Date: Mon Mar 18 14:20:15 2019 +0100

    Add domain scope support for group policies

    This commit adds support for the domain scope type for the group API
    policies. It defines appropriate policies for the reader, member, and
    admin role and adds tests for each case.

    Change-Id: Iaff3c0e45423ef427ef1458250c402c44be4b1d6
    Closes-bug: #1808859
    Partial-Bug: #968696

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.openstack.org/648995

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/648819
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=2727e837d94aa937c9bb5fe68c006a86d4ee0bc7
Submitter: Zuul
Branch: stable/stein

commit 2727e837d94aa937c9bb5fe68c006a86d4ee0bc7
Author: Colleen Murphy <email address hidden>
Date: Tue Mar 26 14:40:00 2019 +0100

    Add release prelude about changing policies

    This change adds a prelude to the release notes to inform operators
    about the changing policy defaults and how to handle them, since these
    are going to be quite a big change and cause a lot of log warnings.

    Change-Id: If067866daa8abbe41027018c260a3e01bddbb92f
    Related-bug: #968696
    (cherry picked from commit 60e0f00326ee41968730f9d72fc77cab26af3d9f)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/648995
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=2c00a6974e35057fd924060fee3d36e6a91fcf95
Submitter: Zuul
Branch: stable/stein

commit 2c00a6974e35057fd924060fee3d36e6a91fcf95
Author: Colleen Murphy <email address hidden>
Date: Mon Mar 18 14:20:15 2019 +0100

    Add domain scope support for group policies

    This commit adds support for the domain scope type for the group API
    policies. It defines appropriate policies for the reader, member, and
    admin role and adds tests for each case.

    Change-Id: Iaff3c0e45423ef427ef1458250c402c44be4b1d6
    Closes-bug: #1808859
    Partial-Bug: #968696
    (cherry picked from commit be452fee80fabe252b2dae3be76c1d46fdd857e4)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/677004

[OpenStack Infra (hudson-openstack)]

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

commit ea7acd80362e27c44a299c70504c21fdc7953e21
Author: Colleen Murphy <email address hidden>
Date: Thu Aug 15 18:39:41 2019 -0700

    Implement system reader role for trusts API

    Currently, the trusts API only allows the "project" scope type, and
    moreover inconsistently enforces different actions based on admin status
    or trustor/trustee relationship: for example, an "admin" can list all
    trusts but not filter by trustor or trustee and cannot get details for a
    single trust, not can they list or get trust roles. This patch changes
    the behavior of the trusts API to allow a system reader to list and get
    details for trusts and trust roles, where previously only a trustor or
    trustee could do so. This helps make the different actions in the trusts
    API consistent with one another and makes the API more useful to a
    deployment auditor. A subsequent patch will add system admin
    functionality.

    This change does not use the oslo.policy deprecation feature for the
    'identity:list_trusts_for_trustor' or 'identity:list_trusts_for_trustee'
    policies as those are new policies introduced in 7717ed3.

    Change-Id: I4e1482643e18fd46e937ffae8b3623cea2d2dd62
    Partial-bug: #1818850
    Partial-bug: #1818846
    Related-Bug: #968696

[OpenStack Infra (hudson-openstack)]

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

commit 6aebf179b8b1b48909ea57666f61bbc080bd6888
Author: Colleen Murphy <email address hidden>
Date: Fri Aug 16 10:38:43 2019 -0700

    Add tests for system member for trusts

    For trusts, a system member is essentially the same as a system reader:
    system members should not be able to create or delete trusts. This
    change adds tests to assert that, but no policy changes are required to
    account for the member role.

    Change-Id: I0acd55f4428708430740bf2c305f664e199dd304
    Partial-bug: #1818846
    Related-Bug: #968696

[OpenStack Infra (hudson-openstack)]

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

commit 9be1caff97355099d25170fe390dd15d6f592d56
Author: Colleen Murphy <email address hidden>
Date: Fri Aug 16 11:14:16 2019 -0700

    Implement system admin for trusts API

    This change enables a system admin to delete trusts. Previously, only
    the trustor or the is_admin admin could delete a trust. This changes
    makes the trusts API more useful to system administrators who need to
    clean up trusts and makes the API consistent with others.

    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.

    Change-Id: Idf13b862f345388bb2372609787947eb43d7ba75
    Closes-bug: #1818846
    Closes-bug: #1818850
    Related-Bug: #968696

[Lance Bragstad (lbragstad)]

I want to provide a holistic view of the work keystone has done to fix this issue.

We fixed this by consuming scope-types [0] and implementing a unified approach to default roles [1]. We also audited our API and separated system-specific APIs from APIs intended for project and domain users. We updated our default policies to reflect intended usage and tracked everything in separate and smaller bug reports [2][3].

As of the Train release keystone supports nine role and scope combinations by default. These roles and scopes give system, domain, and project users support for "reader," "member," and "admin" functionality.

We plan to document all the APIs these personas can access in keystone. We also plan to graduate our API testing to Tempest in some way, shape, or form. This will make it easier for projects to leverage testing utilities if they take the same approach we did.

Everything keystone used to develop this functionality is available for other projects. Mainly, oslo.context, oslo.policy, and keystonemiddleware know how to expose all authorization information necessary to fix this issue. Developers can feel free to reuse the approach keystone used and reference keystone as an example.

[0] https://docs.openstack.org/keystone/latest/contributor/services.html#authorization-scopes
[1] https://docs.openstack.org/keystone/latest/contributor/services.html#how-do-i-incorporate-authorization-scopes-into-a-service
[2] https://tinyurl.com/y4sdg67r
[3] https://tinyurl.com/y6gd46rt

[OpenStack Infra (hudson-openstack)]

Change abandoned by Stephen Finucane (<email address hidden>) on branch: master
Review: https://review.opendev.org/553612
Reason: I'm going to go out on a limb and assume this has stalled and can be abandoned

[OpenStack Infra (hudson-openstack)]

Change abandoned by Stephen Finucane (<email address hidden>) on branch: master
Review: https://review.opendev.org/553613
Reason: One of the patches this depends on has been abandoned and this is failing tests, so I'm going to abandon this in turn. If it's still valid, can you please re-open and update as necessary?

[OpenStack Infra (hudson-openstack)]

Change abandoned by Balazs Gibizer (<email address hidden>) on branch: master
Review: https://review.opendev.org/525772
Reason: This is a pretty old patch with failing tests. Feel free to restore it (or ask gibi on irc to restore it) if you still working on it.

[Lance Bragstad (lbragstad)]

We discussed this topic with system-scope in the Xena PTG last week with glance. Right now, the only really applicable system-scope API for glance is publicize_image (and possibly the metadef API).

Glance is writing up a specification that details the work for a refactor to make adopting system-scope easier and we're targeting that for Xena.

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Gage Hugo <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/keystone/+/311203
Reason: Abandoning since there hasn't been any recent activity, if anyone wants to continue this work, please feel free to restore this or create a new change.

[Adam Young (ayoung)]

Reopoend for Nova since the fix using System Roles seems to have been rejected. The older solution, using Admin_project would deal with the fact that the Nova API requires a project ID on the APIs in question.

[Adam Young (ayoung)]

If it is not fixed in Nova it is not fixed in Keystone, as the solution has to start there.