OpenStack Keystone V3

Keystone V3

Keystone mainly involves the following concepts: User, Tenant, Role, Token. These concepts are briefly described below.

• User: As the name implies, users who use the service can be people, services, or systems, as long as the objects that use Openstack services can be called users.
• Tenant: A tenant that can be understood as a collection of resources owned by a person, project, or organization. You can have a number of users in a tenant who can use the resources in the tenant based on the partitioning of permissions.
• Role: Roles that are used to assign permissions to an operation. The role can be assigned to the user, allowing the user to get the permissions of the role corresponding to the action.
• Token: Refers to a string of bits or strings that are used as tokens for accessing resources. Tokens contain a range of accessible resources and a valid time.

The following diagram illustrates how Keystone and other OpenStack services interact and work together. First, the user provides their own authentication information, such as a user name and password, to Keystone. Keystone will read the data from the database to validate it, such as validation, will return a token to the user, and thereafter all requests from the user will use the token for authentication. If a user requests a virtual machine service from Nova, Nova will send the user's token to Keystone for verification, and Keystone will determine whether the user has permission to do so based on token, and if so, Nova will provide it with the corresponding service. The same is true for the interaction of other components and Keystone.

Figure 1. Keystone Interaction with other services

From the above process can be seen, user role management in the Keystone is very important work. Before Keystone V3, the user's rights management in each user's unit, needs to each user to carry on the role assignment, does not have one to unify a group of users to manage the plan, this has brought the additional work and the inconvenience to the system administrator. In addition, in previous versions of Keystone V3, resource allocations were in Tenant, which did not fit into the real-world hierarchical relationship. If a company has two different projects in Openstack, he needs to manage two Tenant to correspond to each of the two projects and assign roles to the users in the two Tenant. Since there is no higher-level concept on the Tenant, it is not possible to manage the Tenant uniformly, so this brings inconvenience to many Tenant users. In order to solve these problems, Keystone V3 proposed a new concept Domain and Group, this article will introduce the related principles and configuration of Keystone V3.

Back to top of page

Keystone V3 API New features

Keystone V3 made a lot of changes and improvements, we choose the more important to elaborate:

• Change the Tenant to be called Project
• Introducing the concept of Domain
• Introduce the concept of Group

Change Tenant to Project and add the concept of Domain to it, which is more in line with real-world and cloud-service mapping.

V3 uses domain to implement a true multi-tenancy (multi-tenancy) architecture, and domain acts as a high-level container for Project. Customers of cloud services are owners of domain who can create multiple Projects, Users, Groups, and Roles in their own domain. By introducing Domain, cloud service customers can manage multiple project ownership in a unified way without having to manage each project separately from the past.

The group is a set of users ' containers that can be used to add a user to the group and assign roles directly to group, so all users in this group have the role permissions that the group has. By introducing the concept of group, Keystone V3 realizes the management of user group, and achieves the purpose of managing a set of user rights at the same time. This differs from assigning Role directly to User/project in V2, making it easier to manage cloud services.

Figure 2. Diagrams for Domain, Group, Project, User, and Role

2, there are 3 Projects in a domain, which can be assigned directly to domain by Group1, so all users in Group1 will have all Projects in the domain have administrator privileges. You can also assign Role Engineer to Project3 by Group2, so that the User in Group2 only has the appropriate permissions for PROJECT3 without affecting the other Projects.

Back to top of page

Keystone V3 API Call

Here we demonstrate the use of the Keystone V3 API using an instance operation: There is a Domain named "Default" in Openstack, and a Group named "Test_group". We will create a new project in "Default Domain", add a User "Test_user" to "Test_group", and then designate all the users in "Test_group" as a Role in new project.

2. Get token

   Create the JSON file to fill in the necessary validation information, the contents of the Token-request.json file are as follows:

   Figure 3. Get token verification Information

   Request token with the above JSON file and write token to the environment variable "Os_token" for later use.

   Figure 4. Token acquired

4. Create Project

   After the token is successfully obtained, we can use the obtained token to invoke the Keystone V3 API to interact with Keystone. We can create a new Project and name it "Test_project":

   
   
   Figure 5. New Project

   After creating "Test_project", call the API to view the current Projects, and you can see that Test_project has been successfully created:

   Figure 6. View all of the current Project information

6. Add User to Group

   First look at all current Group:

   Figure 7. View all current Group information

   To view all User:

   Figure 8. View all current User information

   Add the User named "Test_user" to the Group named "Test_group"

   Figure 9. Add User to Group

8. assigning Role to Group

   To view all current Role:

   Figure 10. View all current Role information

   Assign a Role named "admin" to Project named "Test_project", Group named "Test_group":

   Figure 11. assigning Role to Group

   View Role of "Test_group" in "Test_project":

   Figure 12. View Group Role information reproduced from http://www.ibm.com/developerworks/cn/cloud/library/1506_yuwz_keystonev3/index.html

   As you can see, a Role named "admin" has been successfully specified for "Test_project"/"Test_group".

OpenStack Keystone V3