Archive

Archive for the ‘keystone’ Category

Relationship among concepts domain, project, role, user group, user and token in OpenStack Keystone

Domain, project, group, roles, users and token are the terms we use to hear a lot in term of OpenStack. Sometime, the meaning of these terms changes. For example, the semantics of the terms project, tenant, domain keep changing even in the Identity API. In this post, I will try to understand the relationship between these concepts. My understanding is based on the OpenStack Identity API V3[1] and the paper by Bo [7]

Screenshot 2016-03-09 11.56.49

Domain:

Domains are the highest level abstraction for resources and users in an OpenStack environment. Domain can directly contain users, user groups and projects. If there is no domain, Identity V3 API assumes a default domain named ‘default’. Domains can also be considered as namespaces. Domain names must be unique across all domains. 

Projects:

Projects are the second highest abstraction in OpenStack environment. Projects can directly contain user groups or users. Project can also contain resources. Note that, one project can be assigned to at most one domain. 

User groups:

As the name says, user groups are group of users. The advantage of having user groups is that by assigning roles to a user group, all users in the group get permissions of the roles. For example, an user group ‘CS6393’ may contain students in the course. By assigning  roles to ‘CS6393’ all students get access to the permissions of the roles. User group names are not global in OpenStack environment. Group names are unique within the owning domain and a group can be assigned to at most domain. 

Roles:

In OpenStack, permissions to do anything is achieved via assignment to roles. Users or user groups  without any role assigned, can do nothing in the OpenStack environment. As in Role Based access Control (RBAC [2]), role contains permission which is a pair of object-type and operation. For example, create object of type VM or network can be considered as a permission. Note that role name are global in OpenStack environment. In other words, no two role can have the same name.

Users:

Users are the active entity in the OpenStack system who can consume resources. Users are assigned to role to be able to carry on their activity. Users without any role, cannot do anything in the system, though it is possible to have users without any roles assigned to them.

Tokens:

Tokens are like sessions/subjects acting on behalf of users. Basically, a token provide a stricter scope for a user. For example, if a user is assigned to two different projects ‘project1’ and ‘project2’, in a token a user can choose which project to work on. Similarly, token also provide scope for domains. Usually, a token can either be scoped for a project or a domain but not both.

Reference:

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

[7] http://profsandhu.com/confrnc/misconf/p131-zhang.pdf

To be continued.

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.

 

TBD.

 

Experimenting OpenStack Keystone V3 API

February 24, 2014 Leave a comment

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

Categories: keystone, openstack Tags: , ,

tempauth – A lightweight Authentication method in OpenStack

February 24, 2014 2 comments

 

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.

 

tempauth used in Swift

Fig1: tempauth used in Swift

 

tempauth credential

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

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/

Categories: keystone, openstack Tags: ,

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.

References:

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

 

To be continued.

Authorization Model in OpenStack (keystone API V2.0)

February 13, 2014 3 comments

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

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:

RBAC-OS-2.0  in Use

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.

Small Org use case

use case 1: Small Org use case

Usecase2:

Large Org Use Case

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

February 8, 2014 3 comments

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:

Authorization_authentication_entities

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:

tenant_list

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.

permission-role-assignment

 

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

Authentication_authorization

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