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.
Note

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

  1. 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         |
    +----------------------------------+-----------------+
  2. View details for a specified role:

    $ openstack role show admin

    Example

    $ openstack role show admin
    +-----------+----------------------------------+
    | Field     | Value                            |
    +-----------+----------------------------------+
    | domain_id | None                             |
    | id        | 01d92614cd224a589bdf3b171afc5488 |
    | name      | admin                            |
    +-----------+----------------------------------+

Note

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.

Note

You can use either the name or ID to specify users, roles, or projects.

Procedure

  1. Create a new-role role:

    $ openstack role create <role_name>
  2. 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
  3. 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 the admin user in the demo project:

    $ openstack role add admin --user admin --project demo
  4. 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 the demo project with the role of admin.

$ openstack role assignment list --user admin --project demo --names
+-------+---------------+-------+--------------+--------+--------+-----------+
| Role  | User          | Group | Project      | Domain | System | Inherited |
+-------+---------------+-------+--------------+--------+--------+-----------+
| admin | admin@Default |       | demo@Default |        |        | False     |
+-------+---------------+-------+--------------+--------+--------+-----------+

3.4. Creating 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            |
+----------------------------------+-----------------+----------------------------------+-------------------+
Note

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.

If you use custom roles, you can create implied associations.

Note

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