Archive for the ‘Access Control’ Category

Access Control model in OpenStack Keystone

For last couple of days,  I am trying to develop  the Access Control (AC) / Authorization model for OpenStack Keystone which is being used by all openstack services.  In my last posts, I tried to formalize the openstack authorization model  as RBAC which I think, is not the correct way to see it. In this post, I would make some correction which reflects my current understanding of OpenStack AC model.


The following discussion, is based on Identity API version 2.0 although version 3.0 is already published and in use in some cases; but I think, 2.0 is easy to understand and so t0 start with.


To my best understanding, the authorization model used by openstack is Rule/Policy Based. Although, openstack/keystone extensively defines roles and Assign user to roles, Role-permission assignment is not mandatory is OpenStack AC model that is , a user can directly get permission without going through a role.


Rule Based Access Control for OpenStack

Rule Based Access Control for OpenStack


For example, following Rules/Policy can be defined in policy.json file:


Rule/Policy1:  Only owner of a VM, can destroy the VM.


Rule/Policy2:  Anyone inside the project ‘developer’ can create a VM inside ‘developer’ project.


Rule/ Policy 3: Anyone having role ‘admin’ can see the project/tenant -list.


Rule/Policy4: Anyone having role ‘admin’ and being member of the ‘developer’ project (or tenant), can update user quota inside ‘developer’ project.


Rule / Policy5: Listing Subnetwork is allowed only to role ‘admin’ or owner. But If the network is shared or external listing subnetwork is also allowed .


Here although, Rule 3/4/5 use role to assign permission to user, policy 1/2 shows that openstack AC can even assign permission to user without Role.





Authorization Model in OpenStack (keystone API V3.0)

February 19, 2014 Leave a comment

In Authorization Model Keystone API V2.0 I have tried to capture the authorization model of Keystone  for API version 2.0 which is no more the latest API version which encourage me to capture the authorization model(lets say it OS_AC_3.0) for API version 3.0 [1]. For naming this model, I deliberately avoided the term RBAC because,  OS_AC_3.0 model no longer confines itself within RBAC territory.

OpenStack Access Control Model for API V3.0

Fig 1 : OS_AC_3.0 Model: OpenStack Access Control Model for API V3.0

It is worth to mention OS_AC_3.0 with the authorization model of API version 2.0 (which I have called RBAC-OS-2.0  model) which was adopted from the minimum RBAC model. Interesting to see when RBAC-OS-2.0  model have only three policy configuration points (Configuration points are shown in fig1 which also applies to fig2 in the same way) whereas OS_AC_3.0 Model has seven configuration points which means there is more flexibility in policy configuration and policy maintenance in the newer model.

RBAC-OS model

Fig2: RBAC-OS-2.0 model

Before delving more into the comparison, we need to focus on the configuration points in OS_AC_3.0.




To be continued.