Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Your specific query about "elevated permissions only within specific tenant" is a bit to general to answer directly. Some things are very easy to control and other things are not. I will try to give you an overview of how the permissions system works so that you can determine if the specific goal you are trying to for is possible.

Roles in keystone are per tenant. When you authorize with keystone you send in a user name, tenant name and password get a token. This token has one or more roles associated with it. For example when you authorize you may have the role "member" or the role "admin".

Policies map roles to capabilities. Each project contains a policy file (or equivalent) that maps roles to capabilites. In most cases the default mapping is very simple. For example the default rule to terminate a vm is admin_or_owner. This means that either a) the tenant name you used when authorizing matches the tenant of the vm or you have the role "admin" in the tenant you used when authorizing.

By default the admin role can do cross-tenant actions. This is the reason for the comment "Typical use is to only create administrative users in a single project". If you have the "admin" role in most cases this means you can do any action on objects owned by ANY TENANT. Perhaps this should have been named "superuser" or some such but this is why giving the admin role in arbitrary tenants is dangerous and usually not what you want.

You can change access to specific actions per tenant. It is possible to modify the role mapping and policy to limit actions in a tenant. For example you could create a role called instance_terminator and require that role for terminating instances. You could also allow access to certain api extensions via special roles.

Elevated permissions only within specific tenant. In my experience, when people ask about this they are requesting a way for a "project admin" to be able to add and remove capabilities to other users in the project. It isn't possible to do this today without some code changes. You would need to create specific roles for all of the actions that you would like control over and you would need a role (call it "projectadmin") that has the ability to a) add and remove users from projects where he has this "projectadmin" role and b) add and remove roles that he has in that project to other users. I think both of these require small changes to the keystone policy checking code to pass in more information when the policy is checked for add_user_to_project and/or add_role