Users and Identity Management

Chapter 1. User Management

1.1. User Management

As a cloud administrator, you can add, modify, and delete users in the dashboard. Users can
be members of one or more projects. You can manage projects and users independently from
each other.

1.1.1. Create a User

Use this procedure to create users in the dashboard. You can assign a primary project and role
to the user. Note that users created in the dashboard are Keystone users by default. To
integrate Active Directory users, you can configure the LDAP provider included in the Red
Hat OpenStack Platform Identity service.

1. As an admin user in the dashboard, select Identity > Users.

2. Click Create User.
3. Enter a user name, email, and preliminary password for the user.
4. Select a project from the Primary Project list.
5. Select a role for the user from the Role list (the default role is _member_).
6. Click Create User.
1.1.2. Edit a User

Use this procedure to update the user’s details, including the primary project.

1. As an admin user in the dashboard, select Identity > Users.

2. In the User’s Actions column, click Edit.
3. In the Update User window, you can update the User Name, Email, and Primary
Project.
4. Click Update User.
1.1.3. Enable or Disable a User

Use this procedure to enable or disable a user. You can disable or enable only one user at a
time. A disabled user cannot log in to the dashboard, and does not have access to any
OpenStack services. Also, a disabled user’s primary project cannot be set as active. A
disabled user can be enabled again, unlike deleting a user where the action cannot be
reversed. A disabled user must be re-enabled for any user-project action in the dashboard.
 1. As an admin user in the dashboard, select Identity > Users.
2. In the Actions column, click the arrow, and select Enable User or Disable User. In
the Enabled column, the value then updates to either True or False.
1.1.4. Delete a User

As an admin user, use this procedure to delete a user using the dashboard. This action cannot
be reversed, unlike disabling a user. Deleted users get delisted from a project’s members' list
for projects it belongs to. All roles associated with the user-project pair are also lost.

1. As an admin user in the dashboard, select Identity > Users.

2. Select the users you want to delete.
3. Click Delete Users. The Confirm Delete Users window is displayed.
4. Click Delete Users to confirm the action.

Chapter 2. Role Management

2.1. Role Management

OpenStack uses a role-based access control (RBAC) mechanism to manage access to its
resources. Roles define which actions users can perform. By default, there are two predefined
roles: a member role that gets attached to a tenant, and an administrative role to enable non-
admin users to administer the environment. Note that there are abstract levels of permission,
and it is possible to create the roles the administrator needs, and configure services
adequately.

2.1.1. View Roles

Use the following command to list the available predefined roles.

$ openstack role list

+----------------------------------+---------------+
| ID | Name |
+----------------------------------+---------------+
| 4fd37c2c993a4acab8e1b5896afb8687 | SwiftOperator |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_ |
| a0f19c1381c54770ae068456c4411d82 | ResellerAdmin |
| ae49e2b796ea4820ac51637be27650d8 | admin |
+----------------------------------+---------------+

To get details for a specified role, run:

$ openstack role show admin

Example
$ openstack role show admin
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | None |
| id | ae49e2b796ea4820ac51637be27650d8 |
| name | admin |
+-----------+----------------------------------+
2.1.2. Create and Assign a Role

As a cloud administrator, you can create and manage roles on the Keystone client using the
following set of commands. Each OpenStack deployment must include at least one project,
one user, and one role, linked together. However, users can be members of multiple projects.
To assign users to multiple projects, create a role and assign that role to a user-project pair.
Note that you can create a user and assign a primary project and default role in the dashboard.

Note

Either the name or ID can be used to specify users, roles, or projects.

1. Create the new-role role:

$ openstack role create [ROLE_NAME]

Example

$ openstack role create new-role

+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | None |
| id | 880c116b6a55464b99ca8d8d8fe26743 |
| name | new-role |
+-----------+----------------------------------+

2. To assign a user to a project, you must assign the role to a user-project pair. To do
this, obtain the user, role, and project names or IDs:
i. List users:

$ openstack user list

ii. List roles:

$ openstack role list

iii. List projects:

$ openstack project list

 3. Assign a role to a user-project pair.

openstack role add --project [PROJECT_NAME] --user [USER_ID] [ROLE_ID]

Example

In this example, you assign the admin role to the admin user in the demo project:

$ openstack role add --project demo --user 895e43465b9643b9aa29df0073572bb2

ae49e2b796ea4820ac51637be27650d8

4. Verify the role assignment for the user admin:

$ openstack role assignment list --user [USER_ID] --project [PROJECT_ID]

Example

$ openstack role assignment list --user 895e43465b9643b9aa29df0073572bb2 --

project demo
+----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
| Role | User |
Group | Project | Domain | Inherited |
+----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
| ae49e2b796ea4820ac51637be27650d8 | 895e43465b9643b9aa29df0073572bb2 |
| 7efbdc8b4ab448b8b5aeb9fa5898ce23 | | False |
+----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
2.2. Implied Roles and Domain-specific Roles
2.2.1. Implied roles

In OpenStack, access control is enforced by confirming that a user is assigned to a specific

role. Until recently, those roles had to be explicitly assigned to either a user, or to a group in
which the user was a member. Identity Service (keystone) has now added the concept of
implied role assignments: If a user is explicitly assigned to a role, then the user could be
implicitly assigned to additional roles as well.

2.2.2. Inference Rules

Implied assignment is managed by role inference rules. An inference rule is written in the
form superior implies subordinate. For example, a rule might state that the admin role
implies the _member_ role. As a result, a user assigned to admin for a project would implicitly
be assigned to the _member_ role as well.
With implied roles, a user’s role assignments are processed cumulatively, allowing the user to
inherit the subordinate roles. This result is dependent on an inference rule being created that
specifies this outcome.

2.2.2.1. Keystone Configuration

For keystone to observe implied roles, the infer_roles setting must be enabled
in /etc/keystone/keystone.conf:

[token]
infer_roles = true

Implied roles are governed by a defined set of inference rules. These rules determine how a
role assignment can result in the implied membership of another role. See Section 2.2.3.1,
“Demonstration of Implied Roles” for an example.

2.2.3. Prevent Certain Roles From Being Implied

You can prevent certain roles from being implied onto a user. For example,
in /etc/keystone/keystone.conf, you can add a ListOpt of roles:

[assignment]
prohibited_implied_role = admin

This will prevent a user from ever being assigned a role implicitly. Instead, the user will need
to be explicitly granted access to that role.

2.2.3.1. Demonstration of Implied Roles

This section describes how to create an inference rule, resulting in an implied role. These
rules control how one role can imply membership of another. The example rule used in the
following procedure will imply that members of the admin role also have _member_ access:

2.2.3.1.1. Assign a Role to the User

1. Retrieve the ID of a user that will have the _member_ role implied. For example:
2. $ openstack user show User1
3. +---------------------+----------------------------------+
4. | Field | Value |
5. +---------------------+----------------------------------+
6. | domain_id | default |
7. | enabled | True |
8. | id | ce803dd127c9489199c89ce3b68d39b4 |
9. | name | User1 |
10. | options | {} |
11. | password_expires_at | None |
+---------------------+----------------------------------+
 12. Retrieve the ID of the demo project:
13. $ openstack project show demo
14. +-------------+----------------------------------+
15. | Field | Value |
16. +-------------+----------------------------------+
17. | description | default tenant |
18. | domain_id | default |
19. | enabled | True |
20. | id | 2717ebc905e449b5975449c370edac69 |
21. | is_domain | False |
22. | name | demo |
23. | parent_id | default |
+-------------+----------------------------------+

24. Retrieve the ID of the admin role:

25. $ openstack role show admin
26. +-----------+----------------------------------+
27. | Field | Value |
28. +-----------+----------------------------------+
29. | domain_id | None |
30. | id | 9b821b2920544be7a4d8f71fa99fcd35 |
31. | name | admin |
+-----------+----------------------------------+

32. Give the User1 user admin privileges to the demo project:

$ openstack role add --user User1 --project demo admin

33. Confirm the admin role assignment:

34. $ openstack role assignment list --user User1 --project demo --effective
35. +----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
36. | Role | User |
Group | Project | Domain | Inherited |
37. +----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
38. | 9b821b2920544be7a4d8f71fa99fcd35 | ce803dd127c9489199c89ce3b68d39b4 |
| 2717ebc905e449b5975449c370edac69 | | False |
+----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
2.2.3.1.2. Create the Inference Rule

Now that you have granted the admin role to User1, run the following steps to create the
inference rule:

1. First, confirm User1’s current role membership:

2. $ openstack role assignment list --user User1 --project demo --effective
3. +----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
4. | Role | User |
Group | Project | Domain | Inherited |
5. +----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
6. | 9b821b2920544be7a4d8f71fa99fcd35 | ce803dd127c9489199c89ce3b68d39b4 |
| 2717ebc905e449b5975449c370edac69 | | False |
+----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+

7. Retrieve the list of role IDs:

8. $ openstack role list
9. +----------------------------------+---------------+
10. | ID | Name |
11. +----------------------------------+---------------+
12. | 9b821b2920544be7a4d8f71fa99fcd35 | admin |
13. | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ |
14. | ea199fe4293745719c2afd3402ed7b95 | ResellerAdmin |
15. | fe8eba5dfd1e4f4a854ad20a150d995e | SwiftOperator |
+----------------------------------+---------------+

16. Create the inference rule. These are currently created using curl. This example uses
the IDs of the roles returned in the previous step. It also runs the command using
the admin_token in keystone.conf:
17. source overcloudrc
18. export OS_TOKEN=`grep ^admin_token /etc/keystone/keystone.conf | awk -F'='
'{print $2}'`
curl -X PUT -H "X-Auth-Token: $OS_TOKEN" -H "Content-type:
application/json"
$OS_AUTH_URL/roles/9b821b2920544be7a4d8f71fa99fcd35/implies/9fe2ff9ee4384b1
894a90878d3e92bab

19. Review the results using the CLI. In this example, User1 has received implied access
to the _member_ role, as indicated by ID 9fe2ff9ee4384b1894a90878d3e92bab:
20. source overcloudrc
21. # openstack role assignment list --user User1 --project demo --effective
22. +----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
23. | Role | User |
Group | Project | Domain | Inherited |
24. +----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+
25. | 9b821b2920544be7a4d8f71fa99fcd35 | ce803dd127c9489199c89ce3b68d39b4 |
| 2717ebc905e449b5975449c370edac69 | | False |
26. | 9fe2ff9ee4384b1894a90878d3e92bab | ce803dd127c9489199c89ce3b68d39b4 |
| 2717ebc905e449b5975449c370edac69 | | False |
+----------------------------------+----------------------------------+----
---+----------------------------------+--------+-----------+

27. Review your inference rules using curl:

Expand
source overcloudrc
export OS_TOKEN=`grep ^admin_token /etc/keystone/keystone.conf | awk -F'='
'{print $2}'`
curl -s -H "X-Auth-Token: $OS_TOKEN" $OS_AUTH_URL/role_inferences | python
-mjson.tool
{
"role_inferences": [
 {
"implies": [
{
"id": "9fe2ff9ee4384b1894a90878d3e92bab",
"links": {
"self":
"https://osp.lab.local:5000/v3/roles/9fe2ff9ee4384b1894a90878d3e92bab"
},
"name": "_member_"
}
],
"prior_role": {
"id": "9b821b2920544be7a4d8f71fa99fcd35",
"links": {
"self":
"https://osp.lab.local:5000/v3/roles/9b821b2920544be7a4d8f71fa99fcd35"
},
"name": "admin"
}
}
]
}
2.2.4. Domain-Specific Roles

Domain-specific roles grant you more granular control when defining rules for roles,
allowing the roles to act as aliases for the existing prior roles. Note that you cannot have a
global role implying a domain-specific role. As a result, if you list the effective role
assignments of a user in a project, the domain-specific roles will not be present.

Domain-specific roles can be created by a user who administers their keystone domain; they
do not have to be administrators of the OpenStack deployment. This means that a domain-
specific role definition can be limited to a specific domain.

Note

Domain-specific roles cannot be used to scope a token. This can only be done with global
roles.

2.2.4.1. Using Domain-Specific Roles

This example describes how to create a domain specific role and review its effect.

1. Create a domain:

$ openstack domain create corp01

2. Create a role that specifies a domain (note that this parameter is distinct from --
domain):
$ openstack role create operators --role-domain domain-corp01