"admin"-ness not properly scoped

Bug #968696 reported by Gabriel Hurley on 2012-03-29
This bug affects 15 people
Affects Status Importance Assigned to Milestone
Adam Young
OpenStack Compute (nova)
Jake Dahn
OpenStack Dashboard (Horizon)
Gabriel Hurley

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.

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?

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