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.

 

Experimenting OpenStack Keystone V3 API

Recently, I experimented with Keystone’s V3.0 API [1] with curl – some of which I gonna post here.

Domains

> create domains:

> List domains:

curl -X GET -H “X-Auth-token:admin” http://10.245.123.32:35357/v3/domains | python -mjson.tool

Projects:

> Create Project:

curl -X POST -H “X-Auth-token:admin” http://10.245.123.32:35357/v3/projects -H “Content-type:application/json” -d @add_project.json | python -mjson.tool

@add_project:
{
“project”: {
“description”: “development”,
“domain_id”: “default”,
“enabled”: true,
“name”: “development”
}
}
> list project:

curl -si -X GET -H “X-Auth-token:admin” http://10.245.123.32:35357/v3/projects -H “Content-type:application/json” | python -mjson.tool

> list users for a project( named development):
curl -X GET -H “X-Auth-token:admin” http://10.245.123.32:35357/v3/projects/?589bc5deb75b4abb8a8bf40932ab8521?/users -H | python -mjson.tool
Users:

> Create user:

curl -X POST -H “X-Auth-token:admin” http://10.245.123.32:35357/v3/users -H “Content-type:application/json” -d @add_user.json | python -mjson.tool

> List user

curl -X GET -H “X-Auth-token:admin” http://10.245.123.32:35357/v3/users | python -mjson.tool
> Role of a user(Alice) assigned to a particular project (‘devepment’):

curl -X GET -H “X-Auth-token:admin” http://10.245.123.32:5000/v3/projects/589bc5deb75b4abb8a8bf40932ab8521/users/2b0498517b2d4db7928ee66e17b61698/roles -H “Content-type:application/json” | python -mjson.tool

Groups:

> List Group
curl -X GET -H “X-Auth-token:admin” http://10.245.123.32:35357/v3/groups | python -mjson.tool

Roles:

> Create a Role Deverloper_R:

curl -X POST -H “X-Auth-token:admin” http://10.245.123.32:35357/v3/roles -H “Content-type:application/json” -d @add_role.json

@add_role.json
{
“role” : {
“name”: “developer_r”
}
}

> List Roles:

curl -X GET -H “X-Auth-token:admin” http://10.245.123.32:35357/v3/roles
? Projects/<project>/users -> not working;

 

References:

1. http://api.openstack.org/api-ref-identity.html#identity-v3

tempauth – A lightweight Authentication method in OpenStack

 

Although keystone is the default  and highly used Identity service which provides means of authentication (and Authorization, which is out of scope in this note)  for OpenStack services and users,  tempauth is really light weight and toy approach for the same purpose used in openstack which in times become handy to work with.  For example, figure 1, shows tempauth being used with Swift proxy server for authentication.

In this post, I would rephrase some details of tempauth.

 

Fig1: tempauth used in Swift

 

Fig2: tempauth credential

 

As depicted in  figure 2 which is an excerpt of  paste deployment configuration file, shows credential (username, password, roles) for users.

 

For example in fig2,  the first highlighted box admin_admin means a user named admin:admin, with password admin with roles admin and reseller_admin. 

 

Similarly, the second line shows an entry of user ‘test:tester’ having password testing with role admin.

 

In this way, in the temp_auth we have  users credential listed. If any user is not in this list, the user will not be authenticated.

How to use tempauth:

Fig 3, shows the curl command for using tempauth for API version 1.0. As you can see tempauth has generated a temporary token for us to work work.

 

Fig3: authentication with tempauth using curl

 

If you want to access the X-Auth-Token and X-Storage-Token in a shell variable to work on, use following command:

 

export STORAGE_URL=`curl -v -H  X-Auth-User:admin:admin -H  X-Auth-Key:admin  http://localhost/auth/v1.0/ 2>&1 | grep X-Storage-Url | awk ‘{print $3}’`

export TOKEN=`curl -v -H  X-Auth-User:admin:admin -H  X-Auth-Key:admin  http://localhost/auth/v1.0/ 2>&1 | grep X-Auth-Token| awk ‘{print $3}’`

Further reading:

 

while learning tempauth, I found this links interesting which you may be interested with.

1. https://swiftstack.com/blog/2012/01/04/swift-tempauth/

2. http://www.gossamer-threads.com/lists/openstack/dev/23040

3. http://www.stephenbroeker.com/2012/03/28/openstack-swift-tempauth-module/

Authorization Model in OpenStack (keystone API V3.0)

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.

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.

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.

References:

[1] http://api.openstack.org/api-ref-identity.html#identity-v3

 

To be continued.

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.

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

Openstack ‘keystone’ user & role management Commands

Most of the the user and role management commands in openstack keystone have to the run as admin user which is specified by the optionn ‘–os-username’ with value ‘admin’ (value can differ according to roles a user assigned to). Here are some handy keystone commands that you may (or need to) encounter while working with openstack ‘keystone’.


#list all tenants in the system:
keystone --os-username admin tenant-list

#List all the users in the system:
keystone --os-username admin user-list

#List all the roles in the system:
keystone --os-username admin role-list

#List all the roles an user (demo) is enrolled to:
keystone --os-username admin user-role-list --user demo (by username)
keystone --os-username admin user-role-list --user-id 5c0ed08c27e94594ba2110462c29d085 (by userid)

#create a new user :
keystone --os-username admin user-create --name sysadmin --pass sysadmin

#Create a new Role:
keystone --os-username demo role-create --name admin_role

#Add a role to a user (add 'admin_role' to 'sysadmin' user):
keystone --os-username admin user-role-add --user sysadmin --role admin_role --tenant demo

#Verify role added correctly:
keystone --os-username admin user-role-list --user sysadmin

#update password of a user:
keystone --os-username admin user-password-update --pass prosun prosun

Now, if you wonder how to correctly specify option for a keystone commands use “keystone help ” to see the details(ex. which option which command expects). For example, hit “keystone help role-create” to know details about role creation.

Exploring directories and files in Openstack ‘keystone’

After I had an occasion to explore openstack ‘keystone’, I decided to note down few things I noticed in my journey.
Directory Structure:
keystone have a very organized directory structure(which is also analogous to other openstack components). keystone has the following directories:

assignment/ auth/ catalog/ common/ contrib/ credential/ identity/ locale/ middleware/ openstack/ policy/ tests/ token/ trust/

Each directory (except few ex: assignment and middleware, locale) have routers.py and controllers.py file which means that each directory is supposed to reroute url and match to actions in its corresponding controllers. For example, if the url is like ‘../user/tokens/’, routes.py inside the ‘token’ directory will be called and controllers.py inside the token directory will have corresponding matching action. This is a pretty good organization. The ‘contrib’ directory contains contributors code and if you add new functionality to keystone (ex. adding session in keystone) you would preferably add it inside ‘contrib’ directory.

Another thing to notice is that everything inside ‘ openstack/common’ directory is common to the whole openstack system. ‘openstack/common/policy.py’ file, for example, implements policy check() mechanism that is used by the whole openstack framework for enforcing policy check.

Files: After kinda skimming over the files in the keystone directory, I have the following insight on “which file do what stuff” (view from thousand miles above):


/opt/stack/etc/policy.json
-- Another file similar to /etc/keystone/policy.json
-- I do not know how it differ from /etc/keystone/policy.json

/opt/stack/keystone/keystone/controllers.py
-- resolve version (2.0/ 3.0) from given url and calls next steps accordingly.

/opt/stack/keystone/keystone/notification.py
-- notifies by sending email for informing admin / stuff for certain actions

/opt/stack/keystone/keystone/auth/routers.py
-- This file is used to match corresponding controller and action from pattern in url
-- works with url like (/auth/tokens).
-- route mapper for check token, validate_token, revoke_token()

/opt/stack/keystone/keystone/policy/controllers.py
-- policy for version 3. Seems not so important for version 2.0.

/opt/stack/keystone/keystone/policy/core.py
-- Probably, interface for get_policy(), update_policy(), delete_policy() and so on..

/opt/stack/keystone/keystone/policy/routers.py
-- loading some script, have only import statements.

/opt/stack/keystone/keystone/policy/backends/rules.py
-- policy engine for keystone. In fact, this is a wrapper for keystone.openstack.common

(common_policy file) which implements sets_rule and check method.,
-- Policy path (which is /etc/keystone/policy.conf) is set here

/opt/stack/keystone/keystone/openstack/common/policy.py
-- Implements set_rules, check method for policy restrictions
-- We can enumerate here all the policy rules that are checked against a given action.

/opt/stack/keystone/keystone/common/wsgi.py
-- Prepare context variable that is passed along subsequent calls in keystone.
-- Class Application member method __call__(), finds appropriate method to call and call it

with context variable.
-- assert_admin() (which is used to ensure admin priviledge) is implemented here.

/opt/stack/keystone/keystone/common/router.py
-- seems to create router path and corresponding controller, action mapping

/opt/stack/keystone/keystone/identity/controllers.py
-- implements the subcommand associated with keystone . ex. keystone user-list

/opt/stack/keystone/keystone/openstack/common/policy.py
-- policy check() method implements here.
-- Stuffs here work for all openstack components(which can also be infurred by '/openstack/common/' as it occours in the path name).