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.
2.1. SRBAC in Red Hat OpenStack Services on OpenShift Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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
memberrole is allowed to create, read, update, and delete resources that are owned by the scope in which they are a member. - reader
-
The
readerrole 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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
- 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 readerpersona is useful for auditors if the audit does not require access to sensitive information.
Additional personas based on the domain scope are not available for use.
2.2. Assigning roles in Red Hat OpenStack Services on OpenShift Copy linkLink copied to clipboard!
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
adminrole assigned to your user account to assign roles.
Procedure
Use syntax similar to the following command to provide a user a role with a
projectscope:$ openstack role add --user user1 --user-domain Default --project demo --project-domain Default <role>where:
<role>-
Specifies either
reader,member, oradmin.
Use syntax similar to the following command to provide a user a role with a
systemscope:$ openstack role add --user user1 --user-domain Default --system all <role>