Chapter 3. Managing roles
Red Hat OpenStack Platform (RHOSP) 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 to attach to a project.
- An administrative role to enable non-admin users to administer the environment.
The Identity service (keystone) has also added the reader
role that will show up in role listings. Do not use the reader
role as it has not been integrated into other OpenStack projects, and provides inconsistent permissions across services.
You can also create custom roles specific to your environment.
3.1. Understanding the Red Hat OpenStack Platform admin role
When you assign a user the role of admin
, this user has permissions to view, change, create, or delete any resource on any project. This user can create shared resources that are accessible across projects, such as publicly available glance images, or provider networks. Additionally, a user with the admin
role can create or delete users and manage roles.
The project to which you assign a user the admin
role is the default project in which openstack
commands are executed. For example, if an admin
user in a project named development
runs the following command, a network called internal-network
is created in the development
project:
openstack network create internal-network
The admin
user can create an internal-network
in any project by using the --project
parameter:
openstack network create internal-network --project testing
3.2. Viewing roles with the CLI
As an administrator, you can view the details of existing roles
Procedure
List the available predefined roles:
$ openstack role list +----------------------------------+-----------------+ | ID | Name | +----------------------------------+-----------------+ | 01d92614cd224a589bdf3b171afc5488 | admin | | 034e4620ed3d45969dfe8992af001514 | member | | 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin | | 9369f2bf754443f199c6d6b96479b1fa | heat_stack_user | | cfea5760d9c948e7b362abc1d06e557f | reader | | d5cb454559e44b47aaa8821df4e11af1 | swiftoperator | | ef3d3f510a474d6c860b4098ad658a29 | service | +----------------------------------+-----------------+
View details for a specified role:
$ openstack role show admin
Example
$ openstack role show admin +-----------+----------------------------------+ | Field | Value | +-----------+----------------------------------+ | domain_id | None | | id | 01d92614cd224a589bdf3b171afc5488 | | name | admin | +-----------+----------------------------------+
To get detailed information on the permissions associated with each role, you must audit its access to each API call. For more information see Auditing API access.
3.3. Creating and Assigning roles with the CLI
As an administrator, you can create and manage roles using the Identity service (keystone) client with the following set of commands. Each Red Hat OpenStack Platform deployment must include at least one project, one user, and one role, linked together.
You can assign users to more than one project. To assign users to multiple projects, create a role and assign that role to a user-project pair.
You can use either the name or ID to specify users, roles, or projects.
Procedure
Create a
new-role
role:$ openstack role create <role_name>
To assign a user to a project, first find the user, role, and project names or IDs by using the following commands:
- openstack user list
- openstack role list
- openstack project list
Assign a role to a user-project pair.
$ openstack role add <role_name> --user <user_name> --project <project_name>
The following example assigns the
admin
role to theadmin
user in thedemo
project:$ openstack role add admin --user admin --project demo
Verify the role assignment for the user
admin
:$ openstack role assignment list --user <user_name> --project <project_name> --names
The following example verifies that the
admin
user is assigned to thedemo
project with the role ofadmin
.
$ openstack role assignment list --user admin --project demo --names +-------+---------------+-------+--------------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +-------+---------------+-------+--------------+--------+--------+-----------+ | admin | admin@Default | | demo@Default | | | False | +-------+---------------+-------+--------------+--------+--------+-----------+
3.4. Implied roles
The Identity service (keystone) enforces access control confirming that a user is assigned to a specific role. The Identity service uses implied role assignments. If you assign a user to a role explicitly, then the user can also be assigned to additional roles implicitly. You can view the default implied roles in Red Hat OpenStack Platform:
$ openstack implied role list +----------------------------------+-----------------+----------------------------------+-------------------+ | Prior Role ID | Prior Role Name | Implied Role ID | Implied Role Name | +----------------------------------+-----------------+----------------------------------+-------------------+ | 54454217f38247e5a2131c8a47138d32 | admin | b59703369e194123b5c77dad60d11a25 | member | | b59703369e194123b5c77dad60d11a25 | member | 382761de4a9c4414b6f8950f8580897c | reader | +----------------------------------+-----------------+----------------------------------+-------------------+
The Identity service (keystone) has also added the reader
role that will show up in role listings. Do not use the reader
role as it has not been integrated into other OpenStack services, and provides inconsistent permissions across services.
The role with higher permissions imply permissions associated with the role with fewer permissions. In the default implied roles above, admin implies member, and member implies reader. With implied roles, role assignments of a user are processed cumulatively, so that the user inherits the subordinate roles.
3.4.1. Creating implied roles
If you use custom roles, you can create implied associations.
When you create a new role, it will have the same access policies as the member
role by default. For information on creating unique policies for custom roles, see Using policy files for access control.
Procedure
Use the following command to specify the role that implies another role:
$ openstack implied role create manager --implied-role poweruser +------------+----------------------------------+ | Field | Value | +------------+----------------------------------+ | implies | ab0b966e0e5e411f8d8b0cc6c26fefd1 | | prior_role | 880761f64bff4e4a8923efda73923b7a | +------------+----------------------------------+
Verification
List all implied roles:
$ openstack implied role list +----------------------------------+-----------------+----------------------------------+-------------------+ | Prior Role ID | Prior Role Name | Implied Role ID | Implied Role Name | +----------------------------------+-----------------+----------------------------------+-------------------+ | 54454217f38247e5a2131c8a47138d32 | admin | b59703369e194123b5c77dad60d11a25 | member | | 880761f64bff4e4a8923efda73923b7a | manager | ab0b966e0e5e411f8d8b0cc6c26fefd1 | poweruser | | b59703369e194123b5c77dad60d11a25 | member | 382761de4a9c4414b6f8950f8580897c | reader | +----------------------------------+-----------------+----------------------------------+-------------------+
If the implied association is made in error, you can undo your changes:
openstack implied role delete manager --implied-role poweruser