Role-Based Access Control and Identity Capabilities¶

StarlingX OpenStack uses Keystone’s RBAC model to control exactly who can do what across the platform. Instead of assigning permissions directly to individual users, administrators assign roles within a specific scope — a project, a domain, or the entire system. Each OpenStack service then enforces its own policy rules against those role assignments, keeping identity management separate from policy enforcement.

This topic expands on the access-control model introduced in the Keystone section of OpenStack Services.

How the Model Works ¶

The RBAC model connects four elements into a single authorization chain:

A user authenticates against Keystone and receives a token.
The token encodes the user’s role assignments within one or more scopes.
The user presents the token with every API request.
The target service evaluates the request against its policy file and permits or denies the operation based on the role and scope.

Because each service owns its own policy rules, operators can tailor access granularly — tightening Cinder policies for storage operations while relaxing Nova policies for developers who need to iterate quickly.

Core Identity Concepts ¶

Domains — Top-level containers that group projects, users, and groups. Domains enable multi-tenancy by letting separate organizations manage their own identity resources independently without interfering with one another.
Projects — Organizational units that own resources such as instances, volumes, and networks. Users gain access to those resources through role assignments scoped to the project.
Roles — Named labels (for example, admin, member, reader) that carry no inherent meaning on their own. Their power comes from the policy rules each service defines to map roles to permitted API actions.
Groups — Collections of users that receive role assignments collectively, simplifying administration when many users need the same level of access.

Tokens and Authentication ¶

After a user authenticates successfully, Keystone issues a short-lived token that encodes the user’s identity and role assignments. The user presents this token with every subsequent API request, eliminating the need to transmit credentials repeatedly and reducing exposure risk.

Tokens are scoped — each token is valid only for the project or domain specified at authentication time. If a user holds roles in multiple projects, they obtain a separate token for each scope they need to access.

Policy Enforcement ¶

Each OpenStack service maintains its own policy file (typically policy.yaml) that maps API operations to required roles. When a request arrives, the service extracts the role and scope from the token and checks them against the policy rules before allowing the operation to proceed.

This separation means:

Keystone handles who you are (authentication and role assignment).
Each service handles what you can do (authorization through policy rules).

Operators can customize policy files to match organizational needs — for example, granting a security-auditor role read-only access to Neutron security groups without exposing compute or storage APIs.

Least Privilege at Scale ¶

The combination of scoped roles and per-service policies supports the principle of least privilege across the entire deployment. An operator can grant a user the reader role in one project for read-only monitoring while assigning member in another project for resource creation — without ever granting broad administrative rights.

This granular approach scales cleanly with organizational growth: new teams receive their own projects and domain boundaries, inheriting the same enforceable access rules without requiring changes to the platform’s security posture.