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
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.
TBD.
