[openstack-dev] [cross-project] "Admin" ness not properly scoped

Adam Young ayoung at redhat.com
Thu Jul 23 14:35:57 UTC 2015

I a user has an admin role anywhere, they have it everywhere.  This is 
bug https://bugs.launchpad.net/keystone/+bug/968696 and, in order to fix 
it we are going to have to adjust our thinking on policy checks.

Here is the theory:
A user is assigned a role on a project.  Policy uses the roles assigned 
in the token to see if the user has access to the object.

This breaks down in practice.  The policy checks either look for a role  
OR a project.

The role is almost always "Admin"

If that fails, then look to see if the user has a project assigned in 
the token.

What this means is the if a user is assigned "admin" on any project, 
they are assigned admin for everything.

Fixing this is going to require a change to how we write policy.

Each policy rule needs to have two parts:

1.  Match the scoped of the token (project for everything that is not 
Keystone, project or domain for Keystone).

2.  Match the role.

Only the second part should ever be changed on a deployment.  It is ok 
to take a rule that is normally executable by A Member and say that it 
is Admin only.  or, if you are so included, define new roles, like 
Manager, which can perform some operations different than Member or Admin.

The first part should not be modified.  It is an engineering decision to 
say "here is where we find the scope in this API.  How to find the Scope 
varies from call to call, and changing that part of the rule is likely 
to break the policy check.

There should be no  "Global Admin Tokens."  They are a security risk, 
and violate the principal of Least Privilege. 

More information about the OpenStack-dev mailing list