Skip to main content

​
Overview

Roles are the foundation of Xloud’s role-based access control (RBAC) system. A role grants a set of permissions and is always assigned in the context of a user + project (or user + domain) pair. Xloud ships three built-in roles — admin, member, and reader — and supports creating custom roles to match your organizational requirements.
Prerequisites
  • CLI authenticated with admin credentials — see CLI Setup
  • Dashboard: logged in as an admin user
  • To create or modify roles you need the admin role on the system scope

​
Built-in Roles

Xloud ships three standard roles that cascade via implied role inheritance:
RolePermissionsTypical Assignment
adminFull API access including administrative endpointsCloud operators, service accounts
memberProject-scoped create, read, update, deleteRegular project members
readerProject-scoped read-only accessAuditors, monitoring service accounts
Implied role hierarchy: admin implies member, and member implies reader. Assigning admin automatically grants all three sets of permissions. You do not need to assign all three roles separately.

​
List and View Roles

Navigate to Admin → Identity → Roles to see all available roles, their IDs, and whether they are domain-scoped.

​
Create a Custom Role

Custom roles let you create named access tiers beyond the three built-in roles. The role itself is just a name — its effective permissions are defined in each service’s policy.yaml file.

Open Roles

Navigate to Admin → Identity → Roles and click Create Role.

Name the role

Enter a descriptive name such as network-operator or image-uploader. Role names are case-sensitive.
Use lowercase, hyphen-separated names (e.g., billing-reader, vpc-admin) to stay consistent with the built-in role naming convention.

Save and assign

Click Submit. The new role is created and available to assign to users. Its permissions are still {} (no extra access) until you add policy rules in each service.
The role appears in Admin → Identity → Roles with a new UUID.

​
Assign Roles

Role assignments always connect a principal (user or group) to a scope (project or domain).

Open project members

Navigate to Admin → Identity → Projects, select the project, and click the Members tab.

Add the user

Click Add Member, search for the user, select the desired role, and click Add.
A user with no role on a project cannot access that project at all — not even read-only. Always assign at least the reader role for users who need visibility into a project.

​
Remove Role Assignments

Navigate to Admin → Identity → Projects → Members, find the user, and click Remove Role.
Before deleting a user account, remove all of their role assignments. A user cannot be deleted while they hold active role assignments on projects or domains.

​
Implied Roles (Role Hierarchies)

Implied roles (also called role inference rules) let you build role hierarchies where assigning one role automatically grants another. This keeps assignments simple while enabling fine-grained permission structures.
Direction matters: Role inference is one-directional. If admin implies member, assigning admin grants both — but assigning member does not grant admin.
openstack implied role create admin --implied-role member

​
Use Case: Fine-Grained Service Roles

You can create service-specific sub-roles and have the member role imply all of them:
Create service-specific sub-roles
openstack role create compute-member
openstack role create network-member
openstack role create volume-member
Have member imply all service sub-roles
openstack implied role create member --implied-role compute-member
openstack implied role create member --implied-role network-member
openstack implied role create member --implied-role volume-member
Now assigning member to a user automatically grants compute, network, and volume access — while you can still assign individual sub-roles for more granular control.

​
Delete a Role

Deleting a role removes it from the system but does not clean up existing role assignments. Any user previously assigned the deleted role loses that access silently. Audit assignments before deleting.
List assignments before deleting (sanity check)
openstack role assignment list --names | grep my-custom-role
Delete the role
openstack role delete my-custom-role

​
Custom Roles and Service Policies

A custom role is just a name until you define what it can do in each service’s policy file. Xloud uses policy.yaml (or policy.json) files in each service container to map role names to allowed API operations. See Policy Management for the full guide on creating per-service policy overrides for your custom roles. Quick example — restrict Compute flavor creation to a custom compute-admin role:
/etc/xavs/nova/policy.yaml
"os_compute_api:os-flavor-manage:create": "role:compute-admin"

​
Next Steps

Policy Management

Define what each role can do in Nova, Glance, Cinder, and other services via policy.yaml overrides

Projects

Create projects and manage the project hierarchy that roles are assigned within

Users

Create users and manage their project memberships

Domain Management

Organize projects and users into domains with independent namespaces