Authentication and Authorization model in OpenStack

For Authentication and Authorization in OpenStack, following terms or concepts comes very frequently
1. User
2. Tenant
3. Role
4. Token
5. Region
6. Endpoints
7. Services

Without having a mental map how these concepts fit together, it is hard to understand authentication and Authorization in OpenStack. My target for this note is to draw a mental picture for these components in term of OpenStack.

Before getting any further into the discussion, it is worth to mention that current OpenStack Architecture use Role Based Access Control for the Authorization purpose.

Following Picture Show a mapping between Tenant, User, Role and Permissions:

Among these concepts, tenant needs a special attention to understand correctly. As specified at [2],  “A tenant is a group of zero or more users. In nova, a tenant owns virtual machines. In swift, a tenant owns containers. Users can be associated with more than one tenant. Each tenant and user pairing can have a role associated with it.”. Every resources (user, vm, network, object in swift, container)  in openstack is tied to a tenant. All users of the tenant may (or may not ) access these resources based on the role they are assigned to. For example, when we upload an object in swift we have to specify the tenant (if not, by default it takes tenant name from running environment which env[‘OS_TENANT_NAME’] ). Only users from the tenant may access the object.  For example, following command, uploads an object only accessible for users in the tenant demo swift  –os-tenant-name=demo  upload container2 n-api.log

In order to see tenant list  in the system:

Similarly, keystone –os-username=admin user-list   shows all users in the system and  keystone –os-username=admin role-list   shows available role in the system. You can anytime create user, role, tenant and associate tenant with user, user with role and so on using the keystone command with admin privilege.

Permission-Role assignment is implemented differently in each service. For example, following excerpt from [3] show permission role assignment for nova-compute service.

 

Authentication & Authorization in a nutshell:

The key to authentication in the identity service keystone is ‘Token’. Whenever keystone authenticate a user, it generate a token for that user. and when the user need to perform some action in some other services in Openstack, user shows the token to the service. The service (ex. Nova) validates the token and see if the user has required role to perform the requested action. This process is illustrated in the following figure

Here it is worth to mention that, a generated token is attached to the tuple (user, role,tenant). When any change happens to ‘user’, ‘role’ or ‘tenant’ previously generated  token will be revoked.

For example,  While generating a token, user ‘demo’ had role ‘admin1’ and was associated with tenant ‘tenant1’. Now, if the user is revoked from the role ‘admin’ all generated token that was associated with (demo,admin1,tenant1) will be revoked.

As I have mentioned earlier that, OpenStack uses Role Based Access Control(RBAC)[1], Most of the nitty-gritty of RBAC also applies to keystone / OpenStack.

For example, lets focus on ‘role-delegation’. Lets have a usecase that shows why keystone need role delegation.

Usecase1: Bob is the system admin (having role = ‘system-admin’) who create new virtual machine (permission=create-vm)  for this team. Now, before going to a vacation, Bob delegates this system-admin role to alice so that she can create new virtual machine on behalf of Bob during his absence. So, keystone need to ability to delegate role.

So far, I have not talked about region, endpoints and services. Besides, I have also missed out trust issues. Hopefully, in some other post, I will talk about these.

TBC.

References:

[1]. http://profsandhu.com/journals/computer/i94rbac(org).pdf

[2] http://docs.openstack.org/grizzly/openstack-compute/admin/content//adding-users-tenants-and-roles-with-python-keystoneclient.html#tenants

[3] https://github.com/openstack/nova/blob/master/etc/nova/policy.json