"admin"-ness not properly scoped

Bug #968696 reported by Gabriel Hurley on 2012-03-29
316
This bug affects 45 people
Affects Status Importance Assigned to Milestone
Cinder
Undecided
Unassigned
Glance
High
Unassigned
OpenStack Compute (nova)
Wishlist
Lance Bragstad
OpenStack Dashboard (Horizon)
Critical
Gabriel Hurley
OpenStack Identity (keystone)
High
Lance Bragstad
neutron
Undecided
Unassigned
puppet-keystone
Undecided
Unassigned

Bug Description

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.

summary: - "admin"-ness not propoerly scoped
+ "admin"-ness not properly scoped
description: updated
description: updated
Changed in horizon:
importance: Undecided → Critical
assignee: nobody → Gabriel Hurley (gabriel-hurley)
status: New → Confirmed
Dolph Mathews (dolph) wrote :

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.

Changed in keystone:
status: New → Confirmed

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

Gabriel Hurley (gabriel-hurley) wrote :

@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) wrote :

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) wrote :

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.

Tom Fifield (fifieldt) on 2012-06-07
Changed in nova:
status: New → Confirmed
Thierry Carrez (ttx) wrote :

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.

no longer affects: nova
Joseph Heck (heckj) wrote :

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

Changed in keystone:
importance: Undecided → Low
Gabriel Hurley (gabriel-hurley) wrote :

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) wrote :

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.

Changed in horizon:
milestone: none → folsom-2

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

Changed in horizon:
status: Confirmed → In Progress

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

Changed in horizon:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2012-07-04
Changed in horizon:
status: Fix Committed → Fix Released
Vish Ishaya (vishvananda) wrote :

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

Changed in nova:
status: New → Fix Committed
milestone: none → folsom-3
importance: Undecided → High
assignee: nobody → Jake Dahn (jakedahn)
Thierry Carrez (ttx) on 2012-08-16
Changed in nova:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2012-09-27
Changed in horizon:
milestone: folsom-2 → 2012.2
Thierry Carrez (ttx) on 2012-09-27
Changed in nova:
milestone: folsom-3 → 2012.2
Dolph Mathews (dolph) wrote :

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.

Changed in keystone:
importance: Low → High
Bryan Murray (bryan-murray) wrote :

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) wrote :

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.

Changed in keystone:
assignee: nobody → Adam Young (ayoung)
Arvind Tiwari (arvind-tiwari) wrote :

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) wrote :

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

David Chadwick (d-w-chadwick) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

Changed in neutron:
status: New → Incomplete
Song Li (lisong-cruise) wrote :

@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?

1 comments hidden view all 122 comments
Adam Young (ayoung) wrote :

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.

Thierry Carrez (ttx) on 2015-07-23
Changed in nova:
status: Fix Released → Confirmed
milestone: 2012.2 → none
assignee: Jake Dahn (jakedahn) → nobody
Adam Young (ayoung) wrote :

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) wrote :

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.

Changed in cinder:
assignee: nobody → Brent Roskos (broskos)
status: New → In Progress

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

Changed in cinder:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2015-09-03
Changed in cinder:
milestone: none → liberty-3
status: Fix Committed → Fix Released
tags: added: keystone rbac
Adam Young (ayoung) wrote :

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

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

Changed in keystone:
status: Confirmed → In Progress
Thierry Carrez (ttx) on 2015-10-15
Changed in cinder:
milestone: liberty-3 → 7.0.0
Kyle Mestery (mestery) on 2015-11-02
Changed in neutron:
assignee: nobody → Kevin Benton (kevinbenton)
status: Incomplete → Triaged
tags: removed: rbac
Changed in neutron:
assignee: Kevin Benton (kevinbenton) → nobody
Adam Young (ayoung) on 2015-12-10
Changed in puppet-keystone:
assignee: nobody → Adam Young (ayoung)
Changed in keystone:
milestone: none → mitaka-2
Changed in keystone:
status: In Progress → Fix Released
Ian Cordasco (icordasc) on 2016-01-12
Changed in glance:
status: New → Triaged
importance: Undecided → High
Sean Dague (sdague) on 2016-02-19
Changed in nova:
importance: High → Wishlist
Changed in glance:
assignee: nobody → Sharat Sharma (sharat-sharma)
status: Triaged → In Progress
Changed in nova:
status: Confirmed → In Progress
assignee: nobody → Sharat Sharma (sharat-sharma)
Adam Young (ayoung) on 2016-09-30
description: updated
Changed in nova:
status: In Progress → Confirmed
Changed in nova:
assignee: Sharat Sharma (sharat-sharma) → Adam Young (ayoung)
status: Confirmed → In Progress
Adam Young (ayoung) on 2016-10-10
Changed in cinder:
assignee: Brent Roskos (broskos) → Adam Young (ayoung)
Changed in glance:
assignee: Sharat Sharma (sharat-sharma) → Adam Young (ayoung)
Changed in neutron:
assignee: nobody → Adam Young (ayoung)
Adam Young (ayoung) on 2016-10-11
Changed in keystone:
status: Fix Released → In Progress
Changed in keystone:
milestone: mitaka-2 → none
Changed in nova:
assignee: Adam Young (ayoung) → Matthew Edmonds (edmondsw)
Adam Young (ayoung) on 2016-10-14
Changed in nova:
assignee: Matthew Edmonds (edmondsw) → Adam Young (ayoung)
Changed in nova:
assignee: Adam Young (ayoung) → Matthew Edmonds (edmondsw)
Changed in nova:
assignee: Matthew Edmonds (edmondsw) → Adam Young (ayoung)
Changed in keystone:
assignee: Adam Young (ayoung) → Matthew Edmonds (edmondsw)
Changed in keystone:
assignee: Matthew Edmonds (edmondsw) → Adam Young (ayoung)
Changed in keystone:
assignee: Adam Young (ayoung) → Gage Hugo (gagehugo)
Changed in nova:
assignee: Adam Young (ayoung) → Gage Hugo (gagehugo)
Changed in keystone:
assignee: Gage Hugo (gagehugo) → Adam Young (ayoung)
Adam Young (ayoung) on 2017-06-06
Changed in glance:
assignee: Adam Young (ayoung) → nobody
Changed in cinder:
assignee: Adam Young (ayoung) → nobody
Changed in neutron:
assignee: Adam Young (ayoung) → nobody
Changed in keystone:
assignee: Adam Young (ayoung) → nobody
Changed in puppet-keystone:
assignee: Adam Young (ayoung) → nobody
Changed in keystone:
assignee: nobody → Gage Hugo (gagehugo)
Changed in keystone:
assignee: Gage Hugo (gagehugo) → Adam Young (ayoung)
Changed in keystone:
assignee: Adam Young (ayoung) → Lance Bragstad (lbragstad)
Changed in keystone:
assignee: Lance Bragstad (lbragstad) → Adam Young (ayoung)
Changed in nova:
assignee: Gage Hugo (gagehugo) → Adam Young (ayoung)
Adam Young (ayoung) on 2017-10-31
Changed in keystone:
assignee: Adam Young (ayoung) → nobody
Changed in nova:
assignee: Adam Young (ayoung) → nobody
42 comments hidden view all 122 comments
Matthew Edmonds (edmondsw) wrote :
Changed in nova:
assignee: nobody → Adam Young (ayoung)

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

Changed in keystone:
assignee: nobody → Adam Young (ayoung)

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

Changed in nova:
assignee: Adam Young (ayoung) → Lance Bragstad (lbragstad)

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

Change abandoned by ayoung (<email address hidden>) on branch: master
Review: https://review.openstack.org/384148
Reason: To avoid confusing people, I am going to abandon this patch. I've kept it around until the System-Role approach showed it had traction and was going to replace it, but now it is causing confusion. I greatly appreciate the +2, but its a bout 14 months too late.

Change abandoned by ayoung (<email address hidden>) on branch: master
Review: https://review.openstack.org/520845
Reason: Abandoning in favor of Session scope

Change abandoned by ayoung (<email address hidden>) on branch: master
Review: https://review.openstack.org/384655
Reason: Abandoning in favor of Session scope.

Change abandoned by ayoung (<email address hidden>) on branch: master
Review: https://review.openstack.org/257636
Reason: Abandoning in favor of session scope

Changed in keystone:
assignee: Adam Young (ayoung) → Lance Bragstad (lbragstad)

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

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

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

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

commit 239bed09a922d6076711ca5c112be6299fa0f0bb
Author: Lance Bragstad <email address hidden>
Date: Tue Aug 21 20:41:38 2018 +0000

    Implement scope_type checking for credentials

    This change adds tests cases for the default roles keystone
    supports at install time. It also modifies the policies for the
    credentials API to be more self-service by properly checking
    for various scopes.

    Closes-Bug: 1788415
    Partial-Bug: 968696

    Change-Id: Ifedb7798c96930b6cc0f91159a14a21ac4b02f9f

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

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

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

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

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

commit 9e8849561bb05f52379531bfc69da8c348f97b28
Author: Lance Bragstad <email address hidden>
Date: Wed Sep 26 16:47:39 2018 +0000

    Implement system reader role in domains API

    This commit introduces the system reader role to the API, making it
    easier for administrators to delegate subsets of responsibilities to
    the API by default.

    Subsequent patches will include domain support for:

      - system members test coverage
      - system admins functionality
      - domain user test coverage
      - project user test coverage

    Change-Id: I2e0a5de931049627e6ceb48b1c0e44205f3388e1
    Partial-Bug: 1794376
    Partial-Bug: 968696

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

commit d5a57414b4d69d5c10e767a94795deb0bc003612
Author: Lance Bragstad <email address hidden>
Date: Thu Sep 27 18:15:48 2018 +0000

    Implement system member role domain test coverage

    This commit introduces the system member role to the API, making sure
    system members can execute readable operations, leaving writable
    domain operations to system administrators.

    Subsequent patches will include domain support for:

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

    Change-Id: I1d21ba562b007b43fc36a7a2010d35591ca3bae5
    Partial-Bug: 1794376
    Partial-Bug: 968696

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

commit 7fa424f1de1ac29c2d34d02cae04b845df5837b1
Author: Lance Bragstad <email address hidden>
Date: Thu Sep 27 18:26:48 2018 +0000

    Implement system admin role in domains API

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

    Subsequent patches will include domain support for:

      - domain user test coverage
      - project user test coverage

    Change-Id: Ic9a789dc3f34d9735de3b4bc4bd48b41190cbfba
    Closes-Bug: 1794376
    Partial-Bug: 968696

Change abandoned by Lance Bragstad (<email address hidden>) on branch: master
Review: https://review.openstack.org/611179
Reason: This has been broken into a more reviewable series, starting here [0].

[0] https://review.openstack.org/#/c/605485/15

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

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

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

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

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

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

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

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

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

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

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

Displaying first 40 and last 40 comments. View all 122 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers