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.
https://en.wikipedia.org/wiki/Principle_of_least_privilege.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
