Chapter 2. Secure role based access control in Red Hat OpenStack Services on OpenShift


Configure secure role-based access control (SRBAC) in Red Hat OpenStack Services on OpenShift (RHOSO) to enforce granular access to policies. Implementing SRBAC limits users 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 RHOSO 18.0 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.

Understand secure role-based access control (SRBAC) personas in Red Hat OpenStack Services on OpenShift (RHOSO) to enforce granular access control. These personas define the specific scope and actions allowed for users, ensuring they have only the permissions necessary for their tasks.

The Identity service (keystone) implements secure roles using personas, which are scope-specific roles. You can assign roles to users or groups that are either project or system scoped.

2.1.1. Roles

Roles define which actions users can perform. There are three OpenStack roles that are available within the project and system scopes.

admin
Granting the admin role in any scope includes all create, read, update, or delete operations on resources and APIs.
member
The member role is allowed to create, read, update, and delete resources that are owned by the scope in which they are a member.
reader
The reader role is for read-only operations, regardless of the scope it is applied to. This role can view resources across the entirety of the scope to which it is applied.

2.1.2. Scope

The scope is the context in which operations are performed. All OpenStack resources are owned by a specific project, so access to those resources is granted by assigning a role to the project scope.

2.1.3. Personas

Project admin
This persona includes create, read, update and delete operations on resources across projects, which includes adding and removing users and other 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 The project-reader persona will not address all auditing use cases.
System admin
System administrators are typically cloud administrators who can affect the behavior of the deployment. Granting a user admin in any scope grants full API access to all APIs in all available scopes.
System members and system readers
System members and system readers have the same authorization and can view all resources within keystone. The system reader persona is useful for auditors if the audit does not require access to sensitive information.
Note

Additional personas based on the domain scope are not available for use.

Assign roles in a secure role-based access control (SRBAC) environment in Red Hat OpenStack Services on OpenShift (RHOSO) to enforce granular access. This configuration limits users to the specific permissions required for their tasks.

You can assign users to the role of admin, member, or reader within either the project or system scope.

Prerequisites

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

Procedure

  1. Use syntax similar to the following command to provide a user a role with a project scope:

    $ openstack role add --user user1 --user-domain Default --project demo --project-domain Default <role>

    where:

    <role>
    Specifies either reader, member, or admin.
  2. Use syntax similar to the following command to provide a user a role with a system scope:

    $ openstack role add --user user1 --user-domain Default --system all <role>
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top