Authorization Model in OpenStack (keystone API V2.0)

Even though in this post I have talked about authentication and authorization model in openstack, here in this note my focus is to dig more into the authorization model from a more theoretical perspective. My object here is to show how much of Role Based Access Control (RBAC) is used in Openstack, which other Access control mechanism have influenced the design. Besides giving a theoretical perspective, I will also model the AC mechanism in Openstack Swift. Enough talk, lets see.

The RBAC model  as proposed by NIST has the following elements. Where user is connected with roles and roles are connected with permission (operation-object) tupple with a n-to-n mapping. The session in this diagram, represent an instantiation of subject-role assignment. This model also supports Role hierarchy.

Fig1: NIST RBAC model

The Authorization model of openstack is not quite similar to the NIST standard but take advantage of the major component of it. For example, role-hierarchy, role-delegation, session, Dynamic Separation of Duty (DSoD), Static separation of Duty (SSoD) is not supported yet till the Icehouse release of Openstack.

Now lets see the way RBAC is supported in OpenStack (OS). Lets call it RBAC-OS-2.0 as it only reflects the Keystone API Version of 2.0 and not of 3.0.

Fig2: RBAC-OS-2.0  model

Before, explaining component of RBAC-OS (user, role,permission (operation, Resource) ) it is worth to understand the concept of Tenant in OS.

Tenant is a group of users but its power is not just limited to grouping the users. Instead tenant is a logical way to organize every resources of OS (role is not included in the resources) and tie them to a specific group of users. For example, Imagine A small organization consisting of few users and certain resources like virtual machines, network, an object Store and so on. With the help of tenant, OS organize every of these resources so that only the members of the organization can utilize their resources in controlled way. This is why, in OS, every resources must be tied to a tenant.

In the RBAC-OS-2.0 model, on the left side of the diagram, it shows  user (specific to a tenant) role assignment and on the right side, it shows role and permission assignment both of which are n-to-n assignments. It is  worth to mention here that OpenStack Policy files ( ex. /etc/nova/policy.conf or /etc/keystone/policy.conf) deals with either USER-ROLE assignment or ROLE-PERMISSION assignment. For example, /etc/nova/policy.conf deals with the later one which is ROLE-PERMISSION assignment.

An Example how RBAC-OS-2.0  model is used in OpenStack:

Fig3: RBAC-OS-2.0 in Use

As we can see, the user ‘nova’ is tied to the tenant ‘service’ and nova user has roles ‘Reseller-admin’, ‘admin’, and ‘_member_’. There are many permissions assigned to the ‘admin’ role out of which in the figure 3 I show only few. Also I assumption is that role-permission assignment varies service to service. For example, the permission for admin role in ‘nova’ varies from the permissions of  ‘admin’ role in ‘swift’.

Business User Cases:

Now we will focus on business usecases where we need to use the RBAC_OS model to tailor the requirements.

usecase-1: A small organization (org1) has two users namely Bob (both an admin and developer) and Charlie (only developer) and two Virtual Machine among one is Deployment_VM and the other is production_VM. While both of Bob and Charlie can access the production VM, only Bob can access the Deployment_VM.

use case 1: Small Org use case

Usecase2:

Large Org Use Case

Limitation of RBAC_OS_2.0 Model:

1. No grouping of Users:  In use case 1, if org1 have hundreds of users, then we have to assign role to each of the user individually. But most of the users would have same privileges thereby, it would have been possible to group similar users and assign role to the group. Keystone API V3.0 solves this problem which I will show in some later blog.

2. Management Inconvenience:  For use case2, imagine that User Bob leaves Development Team( tenant:development) and join the Production Team/Tenant. Now, Bob has to be disassociated from the tester role and re-assigned to the Production Eng. Role. But this dis-association and re-association of role, could have been automated with the fact that Bob Left Development team, so he loses privilege of that team and gains common privilege of the Production Team as he joins it. In fact, this management inconvenience is coming from the limitation mentioned in 1.

3. Lack Of Administrative Domain: When there are multiple tenants that act as part of a big organization (use case2), there is no larger administrative domain that encompasses all the tenants.

Conclusion:

RBAC model as it is may not be very suitable to map management requirement of every (including large and complex) organizations. Some tailored  RBAC would be alleviate some of the problems. But most likely  the RBAC model only may not solve all the bussiness requirement of all organization. To me, Industry as well as academician need  heads up towards building one model (too ambitious) or set of model that can efficiently solve all  cloud access control requirements.