"admin"-ness not properly scoped

Bug #968696 reported by Gabriel Hurley on 2012-03-29
This bug affects 36 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Gage Hugo
OpenStack Dashboard (Horizon)
Gabriel Hurley
OpenStack Identity (keystone)
Gage Hugo

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.

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 :


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 :


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:


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 :


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?

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:


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


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.


    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
Guang Yee (guang-yee) wrote :

How's the proposed solution solving the problem where 'admin' role is admin for everybody? Can we separate Nova admin from Cinder admin?

Adam Young (ayoung) wrote :

Guang, you very easily could do that with custom policy: Have a separate project for Nova and for Cinder, and list both of them in the "admin_project_ids" in Keystone. Communicating the project name or ID with Nova and CInder is out of scope for the current mechanisms.

Thierry Carrez (ttx) on 2015-10-15
Changed in cinder:
milestone: liberty-3 → 7.0.0

Change abandoned by ayoung (<email address hidden>) on branch: master
Review: https://review.openstack.org/233480
Reason: The Admin project needs to be added to the data used for policy enforcement. Just excluding projects will not work with existing APIs

Kyle Mestery (mestery) wrote :

Assigning to Kevin to look at. He did the RBAC work for networks in Liberty. Perhaps expanding the RBAC model to other Neutron resources would address what this bug is looking at.

Changed in neutron:
assignee: nobody → Kevin Benton (kevinbenton)
status: Incomplete → Triaged
Adam Young (ayoung) wrote :

So, a tweak on the approach proposed in Comment 39: We are still going to have an admin project specified in the Keystone config. Instead of limiting tokens with the Admin role to that project, we are going to add an extra value to tokes that are scoped to that project: is_admin_project=True.

This addresses the fact that many APIS require Admin scoped to projects, and will handle the multiple roles for managing service or endpoint specific admins as well.

Change abandoned by Alan Pevec (<email address hidden>) on branch: stable/juno
Review: https://review.openstack.org/217695

Kevin Benton (kevinbenton) wrote :

This isn't related to the RBAC for networks feature in Neutron so I removed that tag. I don't have time to look at this on the Neutron side at the moment so I will un-assign myself for now.

tags: removed: rbac
Changed in neutron:
assignee: Kevin Benton (kevinbenton) → nobody

Reviewed: https://review.openstack.org/240719
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=e7023697a884759716d0a01605825a3af90d4db6
Submitter: Jenkins
Branch: master

commit e7023697a884759716d0a01605825a3af90d4db6
Author: Adam Young <email address hidden>
Date: Sun Oct 11 23:15:52 2015 -0400

    set `is_admin` on tokens for admin project

    Adds two new configuration value:


    If both values are set, and tokens requested for
    projects (only, not domains) that match both will have an
    additional value in them; `is_admin_project=true`

    -- Configuration changes need documentation
    -- Adds optional return values in token validation calls
    -- Should be helpful in making access control decisions

    Implements: blueprint is-admin-project
    Partial-Bug: #968696

    Change-Id: Ic9cf9862739381a30130b4be87075f726736ff88

Adam Young (ayoung) on 2015-12-10
Changed in puppet-keystone:
assignee: nobody → Adam Young (ayoung)
Adam Young (ayoung) wrote :

With the above commit, we have the framework to start fixing this bug. However, we have to deal with existing deployments that expect the existing behavior.

Each of the projects needs a new version of the policy.json file that reflects the current logic, but with the added check for "is_admin_project" performed against the token. The deployment mechanism (devstack, puppet etc) needs to switch over to using the new version of the file, and also to configure the values in the Keystone config file that populate that value on tokens for the appropriate projects.

For exiting deployments, there will be some users that had admin on other-than-admi projects and the site administrators need to determine how to deal with this. Are they going to get admin on the admin project, or will they be limited to operations on the existing set of projects that no longer allow the global admin operations.

Changed in keystone:
milestone: none → mitaka-2

Reviewed: https://review.openstack.org/240720
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=9804081a80ef815a86407a64f967986a7bf9ba25
Submitter: Jenkins
Branch: master

commit 9804081a80ef815a86407a64f967986a7bf9ba25
Author: Adam Young <email address hidden>
Date: Sun Nov 1 11:55:45 2015 -0500

    Updated Cloudsample

    Uses configuration options to determine if a token is for the admin
    project and should be granted admin privileges.

    Closes-Bug: 968696

    Change-Id: Ib23452e171dc90115c77fa5a4b9dc4649054eb0e

Changed in keystone:
status: In Progress → Fix Released

Change abandoned by Sean McGinnis (<email address hidden>) on branch: stable/kilo
Review: https://review.openstack.org/217728
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

Ian Cordasco (icordasc) on 2016-01-12
Changed in glance:
status: New → Triaged
importance: Undecided → High

This issue was fixed in the openstack/keystone development milestone.

Sean Dague (sdague) wrote :

I feel like global admin is something we're not really treating as a bug, but as a new feature that needs to be addressed. Moving to wishlist / feature state for nova for this reason.

Changed in nova:
importance: High → Wishlist
Adam Young (ayoung) wrote :

Please do not downgrade the importance of this bug. With Nova ignoring it, it puts all of the other projects that use the Access Info into a position where they are locked in with the global admin.

Work is actively underway to fix this.

I have a question about this specific feature (use of the is_project_admin flag in the tokens), and most of all the ability to leverage that in Keystone policy and the other service policy files.

I’m running this build:

In my keystone policy file, I did this:

  "admin_required": "role:admin and is_admin_project",
  "identity:list_domains": "rule:admin_required",

I set up the two variables (admin_project_domain_name and admin_project_name) in keystone.conf, and I can obtain a token for a user in the admin project. In the token response, I can see the is_admin_project: true flag which is good.

Somehow though, I get 403 when I try a get /v3/domains with that token.

I’m just looking to see if the code for the policies to leverage that flag is already in in build

From the discussion above, it appears policy changes in the other services has not been merged yet so I'm sticking to just experimenting with Keystone's apis themselves first.

Same behavior with openstack-keystone-

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)

Change abandoned by Sharat Sharma (<email address hidden>) on branch: master
Review: https://review.openstack.org/307648

Adam Young (ayoung) wrote :

Note that the work in this bug is required to enforce policy as required by this one.


description: updated
Changed in nova:
status: In Progress → Confirmed

Change abandoned by abdul nizamuddin (<email address hidden>) on branch: stable/mitaka
Review: https://review.openstack.org/380733

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

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

Reopening the Keystone one as the fix does not work for default policy, which is what most people use.

Changed in keystone:
status: Fix Released → In Progress
Lance Bragstad (lbragstad) wrote :

Untagging this from keystone m2 milestone since there is still work to be done. Adam, is there a new target you're shooting for?

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)

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

commit da0ea57d7e9b8254a877009e77f412684cce3754
Author: Adam Young <email address hidden>
Date: Mon Oct 10 13:41:52 2016 -0400

    Admin API policy enforcement contingent on is_admin_project

    In order for a user with the admin role to be able to perform
    administrative actions, the role must be assigned to a project
    that is deemed the "admin" project in the Keystone server. This
    prevents someone being assigned admin on some random project
    from being admin everywhere.

    Change-Id: Ic4294cc1746702c345259c64bad1e20675a7d9ab
    Closes-Bug: 968696

This issue was fixed in the openstack/cinder development milestone.

I'm not sure if this is still the best place to address the issue, but despite having patched my Newton based lab with commits ca73d296bd5a16435dd35cd0818f4b0a16bc2d02 and ef48072d94f780ebaacee8c3ddf02a68193fa74d ("Fix cloud_admin rule and ensure only project tokens can be cloud admin"), a domain scoped token is still marked as "is_admin_project=True". This has the effect that some projects treat a domain scoped token with the admin role on any given domain as Cloud Admin. This is the case in Neutron for instance.

This happens because when the token is initially created the function that populates the is_admin_project property doesn't set it since it's not a project token. The problem is that "is_admin_project" then defaults to true later on (to support legacy behavior). The "is_admin_project" property function that was added to the Token class in the previously mentioned patch never seems to get called either.

Maybe I'm wrong but a quick glance of Ocata code doesn't make me think that this has changed in that release.

The following quick patch fixes it for me:

--- keystone/token/providers/common.py.orig 2017-03-01 21:09:57.221278528 +0000
+++ keystone/token/providers/common.py 2017-03-01 21:09:51.134244716 +0000
@@ -315,11 +315,15 @@
         if not (admin_project_name and admin_project_domain_name):
             return # admin project not enabled

- project = token_data['project']
- token_data['is_admin_project'] = (
- project['name'] == admin_project_name and
- project['domain']['name'] == admin_project_domain_name)
+ # Since 'is_admin_project' only supported for project scoped tokens,
+ # return False if not project scoped
+ if 'project' in token_data:
+ project = token_data['project']
+ token_data['is_admin_project'] = (
+ project['name'] == admin_project_name and
+ project['domain']['name'] == admin_project_domain_name)
+ else:
+ token_data['is_admin_project'] = False

     def _get_roles_for_user(self, user_id, domain_id, project_id):
         roles = []
@@ -576,8 +580,7 @@
             token_data['bind'] = bind

         self._populate_scope(token_data, domain_id, project_id)
- if token_data.get('project'):
- self._populate_is_admin_project(token_data)
+ self._populate_is_admin_project(token_data)
         self._populate_user(token_data, user_id, trust)
         self._populate_roles(token_data, user_id, domain_id, project_id, trust,

Sorry for patch formatting is my previous comment. Seems Launchpad mangles spaces. Patch attached instead.

Another issue which is orthogonal to the previous one is that despite having added the following patch to Neutron, 2e621eeb1cdfae5ceb3c83eb6befcb954f0b6cec(*) ("Use to_policy_values for policy enforcement"), Neutron completely ignores the "is_admin_project" value set in the token.

This is because neutron-server builds the request context differently than other projects. Instead of using "from_environ" in oslo_context, it does it itself in it's "NeutronKeystoneContext" class.

The fix is to tell it to look at the X_IS_ADMIN_PROJECT header.

Patch attached.

* https://github.com/openstack/neutron/commit/2e621eeb1cdfae5ceb3c83eb6befcb954f0b6cec

The Neutron bug bug above is likely addressed by: https://review.openstack.org/#/c/448538/

Comment #72 should be addressed by https://review.openstack.org/#/c/438035/

Matthew Edmonds (edmondsw) wrote :

Marc FYI, the change you linked in comment 77 was a mistake and is in the process of being reverted.

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

Changed in keystone:
assignee: Adam Young (ayoung) → Gage Hugo (gagehugo)

Reviewed: https://review.openstack.org/464009
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=4a82ab9065a659bbcb838240da113a0509f651aa
Submitter: Jenkins
Branch: master

commit 4a82ab9065a659bbcb838240da113a0509f651aa
Author: Gage Hugo <email address hidden>
Date: Thu May 11 10:34:26 2017 -0400

    Revert change 438035 is_admin_project default

    This change reverts having is_admin_project default to False [0]
    since we currently need to have it revert to True in order to
    account for anyone who has not configured an admin project. This
    will be truely fixed at a later date.

    This also adds comments from another change [1] which clarifies
    the for why this should not be changed at this moment.

    [0] https://review.openstack.org/#/c/438035/
    [1] https://review.openstack.org/#/c/257636/

    Partial-Bug: 968696

    Change-Id: I039bfc8a41d43634ebad545725b9188a82afb990
    Co-Authored-By: Adam Young <email address hidden>
    Co-Authored-By: Matthew Edmonds <email address hidden>

Changed in nova:
assignee: Adam Young (ayoung) → Gage Hugo (gagehugo)
Changed in keystone:
assignee: Gage Hugo (gagehugo) → Adam Young (ayoung)
Adam Young (ayoung) wrote :

setting this to "Wishlist" Nova is, essentially, blocking fixing this issue for all the projects in OpenStack.

Just catching up on this bug since I wasn't subscribed to emails.

Since the patch mentioned in comment 77 was reverted, am I wrong to believe that the patch I attached in comment 74 is still required?

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)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers