Enforce granular control of access to your cloud resources

Implement secure role-based access control (SRBAC) personas to control which resources your users and groups can access and which actions they can perform. SRBAC personas limit users and groups to the specific permissions required for their role, which strengthens the security of your environment.

All users who authenticate to the Identity service (keystone) in Red Hat OpenStack Services on OpenShift (RHOSO) use SRBAC. SRBAC is the updated role-based authentication schema, and is present in all deployments of RHOSO and is used by all the policies to enforce granular control over the access to your cloud and its resources.

The SRBAC personas that the Identity service (keystone) implements are created by combining each scope with their supported roles. You must therefore first understand the available authorization scopes and then the roles that each scope supports.

Scopes

The scope is the authorization context in which operations are performed. RHOSO supports the following three authorization scopes in order from largest to smallest: system, domain, and project. The scope determines the available SRBAC roles.

Note
OpenStack services operate within the servicescope, but this scope and the supported roles are not covered in this topic.

Resources are owned by a specific project, therefore access to these resources is granted by assigning a role to the project scope.

Roles

Roles define the scope-specific SRBAC actions that users and groups can perform.

You can also create custom roles specific to your environment by creating a custom policy.yaml file.

Important
When defining custom policies, ensure that you reference the OpenStack 2023.1 (Antelope) documentation. Newer versions of OpenStack can reference policy keys or values that are not supported in RHOSO 18.0.

RHOSO supports the following scope-specific roles:

  • The admin role within the system scope.

    This role is granted permissions to be the superuser role of OpenStack. For more information about the permissions granted to this admin role, see the Additional resources section below.

    Important
    Granting the admin role in any scope grants full API access to all APIs in all available scopes and all create, read, update, or delete operations on all resources.
  • The manager role within the domain scope.

    This role must be assigned by a user with the admin role and is granted permissions to create, read, update and delete the projects, users, and groups within a specific domain. These permissions enable the manager role to manage the users, groups, and projects within a specific domain and to assign the roles of domain manager, project member and project reader to these users and groups.

  • The following three roles within the project scope:
    admin
    This role is granted permissions to be the superuser role of OpenStack projects and can create or delete users, manage roles and create shared resources accessible across projects. For more information about the permissions granted to this admin role, see the Related information section below. Important
    Granting the admin role in any scope grants full API access to all APIs in all available scopes and all create, read, update, or delete operations on all resources.
    member
    This role is granted permissions to create, read, update, and delete resources that are owned by the specified project.
    reader
    This role is granted permissions to view the project resources. This role is for read-only operations.
Personas

The Identity service (keystone) implements the following SRBAC personas, which are scope-specific roles. These personas help you to define the specific scope and actions that each of your users must perform to ensure they have the permissions necessary to perform their tasks.

Apply the principle of least privilege so that each user or group is given only the permissions they need to perform their tasks.

System admin
System administrators are typically cloud administrators or cloud operators who can manage the behavior of the RHOSO deployment. Granting a user admin in any scope grants full API access to all APIs in all available scopes.
Domain manager

This SRBAC persona enables a user within an organisation to perform the self-administration tasks within a specific domain that previously could only be performed by the cloud operator or System admin. For more information about implementing this persona, see the Related information section below.

The domain manager is granted permissions to create, read, update and delete the projects, users, and groups within a specific domain. These permissions enable this role to manage the users, groups, and projects within a specific domain and to assign the roles of domain manager, project member and project reader to these users and groups.

Project admin
This persona includes create, read, update and delete operations on resources across projects, which includes adding and removing users, groups, and other projects, managing roles and creating shared resources accessible across projects. Granting a user admin in any scope grants full API access to all APIs in all available scopes.
Project member
The project member persona is for users who are granted permission to consume resources within the project scope. This persona can create, list, update, and delete resources within the project to which they are assigned. This persona implies all permissions granted to project readers.
Project reader
The project reader persona is for users who are granted permission to view non-sensitive resources in the project. On projects, assign the reader role to end users who need to inspect or view resources, or to auditors, who only need to view project-specific resources within a single project for the purposes of an audit.

Assign SRBAC scope-based roles
Copy link

When you implement the secure role-based access control (SRBAC) environment, you must assign SRBAC personas, which are scope-based roles to your users and groups to give them access to the required resources and permissions to perform their tasks.

Ensure that the assigned scope-based role provides only the permissions needed to perform the tasks of each user and group. For more information about the supported SRBAC scopes, roles, and personas, see Enforce granular control of access to your cloud resources.

Note
You must have the admin role assigned to your user account to assign roles.

Every role assignment performed by the openstack role add command specifies the name of the applicable scope, the name of the user or group, and applicable scope-specific role.

For example, you can assign a system-specific role to a user:

$ openstack role add --user <user> --system all <system-role>

where:

<user>
Specifies the name or ID of the user.
Note
If you specify the name of the user, then you must provide the --user-domain <domain> argument because user names are only unique within domains. For example: --user user1 --user-domain Default. The user ID is always unique.
<system-role>
Specifies the required role to perform in this system, which is admin.

For example, you can assign a project-specific role to a group:

$ openstack role add --project <project> --group <group> <project-role>

where:

<project>

Specifies the name or ID of the project.

Note
If you specify the name of the project, then you must provide the --project-domain <domain> argument, because project names are only unique within domains. The project ID is always unique.
<group>

Specifies the name or ID of the group.

Note
If you specify the name of the group, then you must provide the --group-domain <managed-domain> argument, because group names are only unique within domains. The group ID is always unique.
<project-role>
Specifies the required role to perform in this project, which is either member or reader.
Note
You can use the openstack role remove command to remove the roles that you have assigned to users and groups.

Admin role permissions and security implications
Copy link

It is important to understand the extensive permissions granted by secure role-based access control (SRBAC) to the admin or superuser role in the project scope. Only assign this role to users and groups who require these extensive permissions to perform their tasks.

Important
Granting the admin role in any scope grants full API access to all APIs in all available scopes and all create, read, update, or delete operations on all resources.

When you assign a user the role of admin in an OpenStack project, this user has permissions to view, change, create, or delete any resource on any project. This user create shared resources that are accessible across projects, such as publicly available glance images, or provider networks. This user can also create or delete users, groups, and other projects 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

Create a domain manager
Copy link

The secure role-based access control (SRBAC) domain manager persona, enables a user within an organization to perform the self administration tasks within a specific domain that previously could only be performed by the cloud operator or OpenStack admin.

About this task
Copy link

The cloud operator or OpenStack admin creates the domain and the user and assigns the SRBAC role of manager to this user in the scope of this domain.

The user uses the openstack CLI to manage the users, groups, and projects in this domain and assign the roles of project reader, project member, and domain manager to these users and groups.

Procedure
Copy link

  1. The cloud operator creates the domain: 
    $ openstack domain create <managed-domain>

    where:

    <managed-domain>
    Specifies the name or ID of the domain that the domain manager will manage.
  2. The cloud operator creates the user in this domain: 
    $ openstack user create --domain <managed-domain> <end-user>

    where:

    <end-user>
    Specifies the name of the required user who will manage this domain.
  3. The cloud operator assigns the role of manager to this user in the scope of this domain: 
    $ openstack role add --user <end-user> --domain <managed-domain> manager

    where:

    <end-user>

    Specifies the name or ID of the user you created in step 2.

    Note
    If you specify the name of the user, then you must provide the --user-domain <managed-domain> argument, because user names are only unique within domains. The user ID is always unique.
    <managed-domain>
    Specifies the name or ID of the domain you created in step 1 that this user will manage.

Domain manager tasks
Copy link

As a domain manager, use the openstack CLI to manage users, groups, and projects within your assigned domain. Assign reader and member roles to add users to projects, or assign manager to delegate domain administration.

Important
Your cloud operator must provide you with a clouds.yaml file to access the cloud and you must install the python-openstackclient package on your workstation.

Create users, groups, and projects

Create a user
$ openstack user create --domain <managed-domain> <user-name> --os-cloud <cloud_name>

where:

<managed-domain>
Specifies the name or ID of your assigned domain.
<user-name>
Specifies the name of this new user.
<cloud_name>
Specifies the name of the cloud detailed in your clouds.yaml file.
Create a group
$ openstack group create --domain <managed-domain> <group-name> --os-cloud <cloud_name>

where:

<group-name>
Specifies the name of this new group.
Create a project
$ openstack project create --domain <managed-domain> <project-name> --os-cloud <cloud_name>

where:

<project-name>

Specifies the name of this new project.

Important
Due to the distributed nature of OpenStack the openstack CLI does not know all the resources that have been created for a project, for example, the volumes, instances, and networks. Each project member must record the names of the resources that they create, so that all these resources can be removed before deleting this project. Otherwise these resources might become orphaned and inaccessible without involving an admin.

Manage group membership

Add a user to a group
$ openstack group add user <group> <user> --os-cloud <cloud_name>
Tip
You can add multiple users to a group, by adding multiple <user> arguments to this command.

where:

<group>

Specifies the name or ID of the group.

Note
If you specify the name of the group, then you must provide the --group-domain <managed-domain> argument, because group names are only unique within domains. The group ID is always unique.
<user>

Specifies the name or ID of the user.

Note
If you specify the name of the user, then you must provide the --user-domain <managed-domain> argument, because user names are only unique within domains. The user ID is always unique.
Check user membership in a group
$ openstack group contains user <group> <user> --os-cloud <cloud_name>
Remove a user from a group
$ openstack group remove user <group> <user> --os-cloud <cloud_name>
Tip
You can remove multiple users from a group, by adding multiple <user> arguments to this command.

Manage the users and groups assigned to projects

Because of the secure role-based access control (SRBAC) of OpenStack, you must add a project-specific role to a user or group before this user or group can access this project. Similarly you must remove the project-specific role from a user or group to prevent them from accessing this project.

OpenStack supports the following two project-specific roles for users and groups:

  • The reader role can view resources of their assigned project.
Note
This role is for read-only operations.
  • The member role is allowed to create, read, update, and delete resources that are owned by their assigned project.
Important
Due to the distributed nature of OpenStack the openstack CLI does not know all the resources that have been created for a project, for example, the volumes, instances, and networks. Therefore each project member must record the names of the resources that they create, so that all these resources can be removed before deleting this project. Otherwise these resources might become orphaned and inaccessible without involving an admin.
Add a project role to a user
$ openstack role add --project <project> --user <user> <project-role> --os-cloud <cloud_name>

where:

<project>

Specifies the name or ID of the project.

Note
If you specify the name of the project, then you must provide the --project-domain <managed-domain> argument, because project names are only unique within domains. The project ID is always unique.
<project-role>
Specifies the required role to perform in this project, which is either member or reader, as described above.
Add a project role to a group
$ openstack role add --project <project> --group <group> <project-role> --os-cloud <cloud_name>
View the roles assigned to a project
$ openstack role assignment list --names --project <project> --os-cloud <cloud_name>
Note
The --names parameter is easier to edit because it displays the readable names of users, groups, projects, roles and domains, instead of IDs. You can omit this parameter if you prefer to see their raw IDs.
Remove a project role from a user
$ openstack role remove --project <project> --user <user> <project-role> --os-cloud <cloud_name>
Remove a project role from a group
$ openstack role remove --project <project> --group <group> <project-role> --os-cloud <cloud_name>

Manage the users and groups assigned to manage this domain

You can add the domain-specific role of manager to users and groups to help you to manage this domain. You can also remove this role from them as needed.

Add the domain manager role to a user
$ openstack role add --domain <managed-domain> --user <user> manager --os-cloud <cloud_name>

where:

<managed-domain>
Specifies the name or ID of this domain.
Add the domain manager role to a group
$ openstack role add --domain <managed-domain> --group <group> manager --os-cloud <cloud_name>
View the manager roles assigned to a domain
$ openstack role assignment list  --names --domain <managed-domain> --os-cloud <cloud_name>
Remove a domain manager role from a user
$ openstack role remove --domain <managed-domain> --user <user> manager --os-cloud <cloud_name>
Remove a domain manager role from a group
$ openstack role remove --domain <managed-domain> --group <group> manager --os-cloud <cloud_name>

Remove users, groups, and projects

Remove a user
$ openstack user delete <user> --os-cloud <cloud_name>
Remove a group
$ openstack group delete <group> --os-cloud <cloud_name>
Remove a project

Ensure that all the resources that have been created for a project, for example, the volumes, instances, and networks are removed before removing the project. Otherwise these resources might become orphaned and inaccessible without involving an admin.

$ openstack project delete <project> --os-cloud <cloud_name>

View roles with the OpenStack CLI
Copy link

View the available roles and their details to verify which roles exist and understand their access levels before you assign them to users.

Before you begin
Copy link

  • You must have the admin role assigned to your user account to list and view roles.

About this task
Copy link

Note
To get detailed information on the permissions associated with each role, you must audit its access to each API call.

Procedure
Copy link

  1. List the available predefined roles: 
    $ openstack role list
  2. View details for a specific role: 
    $ openstack role show <role>

    where:

    <role>
    Specifies with one of the listed roles, for example, member.

User and role audit
Copy link

Audit the secure role-based access control (SRBAC) roles assigned to each user and group to apply the principle of least privilege: each user or group must be given only the permissions they need to perform their tasks and must not have more access than their tasks require.

Red Hat OpenStack Services on OpenShift (RHOSO) implements scope-based SRBAC roles or personas to determine the privileges assigned to users. For more information about the supported SRBAC scopes, roles, and personas, see Enforce granular control of access to your cloud resources.

You can use the following command to determine the roles assigned to the users and groups:

$ openstack role assignment list --names
Note
The --names parameter displays the readable names of users, groups, projects, roles and domains instead of IDs making it easier to audit these. You can omit this parameter if you prefer to see their raw IDs.

Given that the admin role is the OpenStack superuser it is especially important to audit the use of this role when assigned to projects. For more information, see Understanding the OpenStack project admin role permissions.

You can see all the project-scoped users that have the admin role:

$ openstack role assignment list --names --role admin

When auditing the scope-specific SRBAC roles it is helpful to list the roles within their supported scopes.

You can see all the users and groups with system-scoped roles:

$ openstack role assignment list --names --system all
Note
Only the system scope provides this --system all option, all other scopes must be specifically specified.

You can see the roles of all the users and groups within the scope of a specific domain:

$ openstack role assignment list --names --domain <domain>

where:

<domain>
Specifies the name or ID of the required domain.

You can see the roles of all the users and groups within the scope of a specific project:

$ openstack role assignment list --names --project <project>

where:

<project>

Specifies the name or ID of the required project.

Note
If you specify the project name, then you must provide the --project-domain <domain> argument because project names are only unique within domains. The project ID is always unique.