> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt
> Use this file to discover all available pages before exploring further.
# Roles & Role Assignments
> Create custom roles, assign them to users and groups on projects or domains, and build role hierarchies with implied roles in Xloud Identity.
## 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](/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:
| Role | Permissions | Typical Assignment |
| -------- | -------------------------------------------------- | ------------------------------------- |
| `admin` | Full API access including administrative endpoints | Cloud operators, service accounts |
| `member` | Project-scoped create, read, update, delete | Regular project members |
| `reader` | Project-scoped read-only access | Auditors, 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 **Identity > Roles** (admin view) to see all available roles, their IDs, and whether they are domain-scoped.
```bash title="List all roles" theme={null}
openstack role list
```
```bash title="Show role details" theme={null}
openstack role show member
```
```bash title="List all role assignments (with names)" theme={null}
openstack role assignment list --names
```
```bash title="List assignments for a specific user" theme={null}
openstack role assignment list \
--user john.doe \
--names
```
```bash title="List assignments on a specific project" theme={null}
openstack role assignment list \
--project my-project \
--names
```
***
## 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.
Navigate to **Identity > Roles** (admin view) and click **Create 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.
Click **Confirm**. 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 **Identity > Roles** (admin view) with a new UUID.
```bash title="Create a custom role" theme={null}
openstack role create network-operator
```
```bash title="Create a domain-scoped role" theme={null}
openstack role create --domain my-domain billing-reader
```
```bash title="Verify the role was created" theme={null}
openstack role show network-operator
```
After creating the role, define its permissions in the relevant service policy files. See [Policy Management](/services/identity/policy-management) for how to map role names to API operations.
***
## Assign Roles
Role assignments always connect a **principal** (user or group) to a **scope** (project or domain).
Navigate to **Identity > Projects** (admin view), select the project, and click the **Manage User** action (More dropdown).
Click **Add Member**, search for the user, select the desired role, and click **Add**.
```bash title="Assign role to a user on a project" theme={null}
openstack role add \
--user john.doe \
--project my-project \
member
```
```bash title="Assign admin role on a project" theme={null}
openstack role add \
--user alice \
--project ops-project \
admin
```
```bash title="Assign role to a user at domain scope" theme={null}
openstack role add \
--user john.doe \
--domain my-domain \
member
```
```bash title="Assign role to a group on a project" theme={null}
openstack role add \
--group operators \
--project my-project \
member
```
```bash title="Verify the assignment" theme={null}
openstack role assignment list \
--user john.doe \
--project my-project \
--names
```
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 **Identity > Projects** (admin view) > **Manage User** action, find the user, and click **Remove Role**.
```bash title="Remove a role from a user on a project" theme={null}
openstack role remove \
--user john.doe \
--project my-project \
member
```
```bash title="Remove group role assignment" theme={null}
openstack role remove \
--group operators \
--project my-project \
member
```
```bash title="Verify removal" theme={null}
openstack role assignment list \
--user john.doe \
--project my-project \
--names
```
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`.
```bash title="Create an implied role rule (admin implies member)" theme={null}
openstack implied role create admin --implied-role member
```
```bash title="List all implied role rules" theme={null}
openstack implied role list
```
```bash title="Delete an implied role rule" theme={null}
openstack implied role delete 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:
```bash title="Create service-specific sub-roles" theme={null}
openstack role create compute-member
openstack role create network-member
openstack role create volume-member
```
```bash title="Have member imply all service sub-roles" theme={null}
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.
```bash title="List assignments before deleting (sanity check)" theme={null}
openstack role assignment list --names | grep my-custom-role
```
```bash title="Delete the role" theme={null}
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](/services/identity/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:
```yaml title="/etc/xavs/nova/policy.yaml" theme={null}
"os_compute_api:os-flavor-manage:create": "role:compute-admin"
```
***
## Next Steps
Define what each role can do in Nova, Glance, Cinder, and other services via policy.yaml overrides
Create projects and manage the project hierarchy that roles are assigned within
Create users and manage their project memberships
Organize projects and users into domains with independent namespaces