Configure SRBAC policies

Manage service resource access with secure role-based access control (SRBAC) policies. Use these policies to define fine-grained administrative, member, and reader roles within your environment.

RHOSO 18.0 uses Secure role-based access control (SRBAC) by default. SRBAC replaces the legacy admin or owner model from Red Hat OpenStack Platform (RHOSP) 17.1 with a structured system of admin, member, and reader roles operating within project or system scopes. The default services policies enforce this model. There are no deprecated fallback policies.

Important
Avoid using customized roles or policies. Syntax errors or misapplied authorization can negatively impact security or usability. If you need customized roles or policies in your production environment, contact Red Hat support for a support exception.

SRBAC roles and scopes
Copy link

In Red Hat OpenStack Platform (RHOSP) 17.1, the default authorization model relied on two implicit roles and policies defined as combinations of admin or owner checks. This model was inconsistent across services and made it difficult to grant fine-grained access without custom policy overrides.

Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 enforces SRBAC uniformly. The Identity service (keystone) implements secure roles by using personas, which are scope-specific role assignments.

Roles

Three roles are available: admin, member, and reader. They imply one another hierarchically: admin implies member, and member implies reader. The roles have the following permissions:

  • Admin has full create, read, update, and delete (CRUD) operations on all resources within the assigned scope.
  • Member has CRUD operations on resources owned by the scope in which the user is a member, but cannot perform administrative operations.
  • Reader has read-only operations and cannot create, update, or delete resources, regardless of scope.
Note
The legacy member, swiftoperator, ResellerAdmin, and heat_stack_user roles from RHOSP 17.1 are replaced by the three SRBAC roles. If your environment has users assigned to legacy roles, consider reviewing and reassigning them to admin, member, or reader within the appropriate scope.
Scopes

Each role is assigned within one of two scopes: project or system.

  • In the project scope, the role applies to resources within a specific OpenStack project. This is the scope used by cloud users and project administrators. Use the following command to assign a project-scoped member role to a user: 
    $ openstack role add --user user1 --user-domain Default \
    --project demo --project-domain Default member
  • In the system scope, the role applies to system-wide operations that are not owned by any project, such as managing endpoints, hypervisors, or service catalogs. System-scoped reader is useful for auditors or support team members who need read-only visibility across the entire deployment. Use the following command to assign a system-scoped member role to a user: 
    $ openstack role add --user auditor1 --user-domain Default \
    --system all reader

Review existing policies
Copy link

To view existing policies, you generate the policy inside the services pod. There are no policy files on disk. Any policy overrides are injected with customServiceConfig in the OpenStackControlPlane CR.

Procedure
Copy link

  1. To view the complete set of default policies for a service, use oslopolicy-policy-generator inside the service pod: 
    $ oc exec -n openstack <keystone-api-pod> -- \
    oslopolicy-policy-generator \
    --namespace keystone > keystone-policy.yaml
  2. Replace <keystone-api-pod> with the actual pod name. To find the pod name, use the following command: 
    $ oc get pods -n openstack -l service=keystone

    The output uses YAML format. JSON policy files such as policy.json are deprecated. Ensure that new policy override files use the policy.yaml format.

  3. If you migrated policy overrides from Red Hat OpenStack Platform (RHOSP) 17.1, you can check the validity of the policy overrides: 
    $ oc exec -n openstack <nova-api-pod> -- \
    oslopolicy-list-redundant \
    --namespace nova
    • Replace <nova-api-pod> with the correct name of the Compute service (nova)API pod.

    You should remove rules that are in the output of this command from your overrides to reduce maintenance burden and avoid masking future upstream changes.

Policy syntax
Copy link

Policy rules follow the format "<target>": "<check_string>". The target identifies the API action and the check string defines who can perform the API action.

Table 1. String operator definitions
Operator Definition

!

No user can perform this action, including admin.

@ or ""

Any authenticated user can perform this action.

role:<name>

The user must have the specified role.

rule:<name>

Evaluates a named alias rule that is defined elsewhere in the policy.

not, and, or

Standard boolean operators for composing complex rules.
Scope types in SRBAC policies

SRBAC policies include a scope_types attribute that restricts which token scope can call the API. For example, a policy with scope_types: ["system"] can only be called by a user with a system-scoped token. A policy with scope_types: ["project"] requires a project-scoped token. In Red Hat OpenStack Services on OpenShift (RHOSO) 18.0, scope enforcement is enabled by default, denoted by enforce_scope = true and enforce_new_defaults = true in oslo.policy. Attempting to call a system-scoped API with a project-scoped token will return a 403 Forbidden error.

The following is an example SRBAC policy rule for listing hypervisors such as system-scoped or reader role:

"os_compute_api:os-hypervisors:list": "role:reader"
# scope_types: ["system"]

This policy rule only allows users with a system-scoped reader or higher role to list hypervisors. A project-admin cannot list hypervisors because their token is project-scoped.

SRBAC implementation planning
Copy link

Before you deploy Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 with default SRBAC policies, audit your existing user base and role assignments to ensure users are mapped correctly to the new model.

Migration from legacy roles

If you are migrating from Red Hat OpenStack Platform (RHOSP) 17.1, note the following considerations:

  • Users with the legacy admin role should retain the admin role in the appropriate scope, either project or system.
  • Reassign users with member to the member role in project scope.
  • Assign read-only users, such as monitoring tools or auditors, to the reader in the appropriate scope.
  • Service accounts such as nova, neutron, glance, and others are managed by the OpenStack Operator and do not require manual role assignment.
Principle of least privilege

Note the following considerations when implementing least privilege in SRBAC:

  • Assign the reader role to users who only need to view resources such as dashboards, monitoring, or auditing.
  • Assign the member role to users who create and manage their own resources within a project.
  • Reserve the admin role for project administrators or system operators who need full CRUD and administrative operations.
  • Use system scope sparingly. Most cloud users should have project-scoped roles only. System-scoped admin is for infrastructure operators.
Custom roles
RHOSO 18.0 supports creating custom roles, but these roles default to the same access policies as the member role, unless you create explicit policy overrides. The three roles and two scopes present in the SRBAC model covers most access patterns cleanly, so you might not need to create a custom role.

RHOSP 17.1 to RHOSO 18.0 SRBAC comparison
Copy link

If you are already familiar with SRBAC in Red Hat OpenStack Platform (RHOSP) 17.1, it can be useful to note some of the differences between RHOSP 17.1 and Red Hat OpenStack Services on OpenShift (RHOSO) 18.0.

The following table outlines some of the differences between RHOSP 17.1 and RHOSO 18.0:

Table 2. Comparison between RHOSP 17.1 and RHOSO 18.0
RHOSP 17.1 mechanism RHOSO 18.0 equivalent Notes

admin and member roles with implicit owner checks

SRBAC: admin, member, reader roles with project or system scope

Scope enforcement is on by default and cannot be disabled

policy.json stored at /var/lib/config-data/…​

Defaults in code and policy.yaml overrides with customServiceConfig

Use YAML format instead of deprecated JSON policy files

podman exec oslopolicy-policy-generator

oc exec -n openstack <pod> — oslopolicy-policy-generator

Same tool but different container runtime access

Heat policy parameters such as NovaApiPolicies, KeystonePolicies, and others

customServiceConfig in OpenStackControlPlane CR per service

All heat params removed and replaced by single delivery mechanism

podman cp policy.json into container which is immediate and non-persistent

ConfigMap and operator reconciliation which are persistent and auditable)

Changes require operator reconciliation and are not instant

SSH to controller and tripleo-admin for policy inspection

$ oc rsh or $ oc exec into service pods

Auditable in RHOCP API audit log

Custom roles such as PowerUsers with per-action policy overrides

SRBAC admin, member, or reader covers most patterns so custom roles are supported but discouraged

Custom roles default to member permissions without overrides