> For the complete documentation index, see [llms.txt](https://docs.platform9.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.platform9.com/private-cloud-director/identity-and-multi-tenancy/rbac-roles-and-permissions/granular-rbac-roles.md).

# Granular RBAC Roles (Beta)

Reference for PCD's Granular Role-Based Access Control (Beta): the six administrative and user roles, their scope, and how to assign them.

## Overview

{% hint style="danger" %}
**Beta**

Granular Role-Based Access Control is currently in **beta**. Production use is not recommended at this time. If the role options described below are not available in your deployment, contact Platform9 support.
{% endhint %}

In addition to the three legacy roles described in [RBAC Roles and Permissions](/private-cloud-director/identity-and-multi-tenancy/rbac-roles-and-permissions.md), <code class="expression">space.vars.product\_name</code> offers a granular RBAC model with six administrative and user roles, each scoped to a specific layer of the platform: the whole system, a domain, or a single tenant. This model is backed by a dedicated policy engine and is intended for deployments that need finer-grained delegation than the legacy role set provides. For example, it can separate platform-wide infrastructure administration from a service provider's customer-facing administration, or from a single customer domain's own administration.

Granular RBAC does not replace the legacy Admin, Self-Service User, and ReadOnly roles, but the two role sets are mutually exclusive. Assign a user roles from one set or the other, never both.

## The Six Roles

| Role                                        | Scope                         | Intended For                                                                                                                                                                                                                                                                                                                                                                                   |
| ------------------------------------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Platform Admin** (Platform Owner)         | System (all domains)          | Full control across the entire platform: all domains, tenants, and infrastructure. Typically reserved for top-level platform operators.                                                                                                                                                                                                                                                        |
| **Service Provider Domain Admin** (MSP Ops) | System (all customer domains) | Operates the platform on behalf of customer domains: manages users, groups, role bindings, and identity providers across all customer domains, publishes platform images, flavors, and volume types, and provisions external networks. Does not manage hosts, compute clusters, or quotas. This role is system-scoped and cannot be limited to selected customer domains.                      |
| **Customer Domain Admin**                   | Domain                        | Full administrative control within a single customer domain, covering users, groups, tenants, role bindings, and the images, flavors, and volume types published to that domain, without access to other domains or to hosts and clusters. Cannot create, rename, or delete tenants. Intended for a domain's own administrators.                                                               |
| **Tenant Admin**                            | Tenant                        | Full control over resources within a single tenant, plus adding existing users to the tenant, assigning tenant roles, updating existing users in its domain, and setting per-user quotas. Cannot create users or set the tenant's own quotas. Intended for tenant-level administrators.                                                                                                        |
| **Application User**                        | Tenant                        | Can create and manage compute, storage, and networking resources within a tenant. In the UI, Application Users see and operate only the VMs they created; storage and networking resources are visible tenant-wide. Cannot migrate VMs, manage users or role assignments, set quotas, or manage platform catalogs.                                                                             |
| **Tenant User**                             | Tenant, own resources only    | Can create and manage only the VMs, volumes, ports, snapshots, and SSH key pairs they own within a tenant, and view other tenant resources such as networks and security groups. Cannot create networks, routers, or security groups, cannot migrate VMs, and cannot manage users, roles, or quotas. Intended for users who need to run their own workloads without broader management rights. |

{% hint style="info" %}
**Service Provider Domain Admin scope**

**Service Provider Domain Admin** is a system-scoped role. Assigning this role grants access across all customer domains in the deployment; there is no option to assign it to only specific customer domains. Use **Customer Domain Admin** when access must be limited to one selected customer domain.
{% endhint %}

## Assigning Granular RBAC Roles

Granular RBAC roles are assigned directly from the standard user- and domain-management screens. Each role belongs to one of three access-level tiers, and the tier determines where in the UI you assign it.

To see the role definitions available in your deployment, navigate to **Settings** > **Tenants and Users** > **Roles**.

| Access Level            | Assigns a role for...                                                                                                                                         | Available Roles                                                          |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| **System-Level Access** | All domains, and all tenants within those domains. Service Provider Domain Admin access applies to all customer domains and cannot be restricted to a subset. | Platform Admin (Platform Owner), Service Provider Domain Admin (MSP Ops) |
| **Domain-Level Access** | The selected domain and its tenants.                                                                                                                          | Customer Domain Admin                                                    |
| **Tenant-Level Access** | Specific tenants within the selected domain (one role per tenant).                                                                                            | Tenant Admin, Application User, Tenant User                              |

### From Create User

{% hint style="info" %}
**Who can create users**

Creating a user is a domain-level action. **Platform Admin** can create users in any domain, **Service Provider Domain Admin** is system-scoped and creates users in customer domains, and **Customer Domain Admin** can create users in its own domain. **Tenant Admin** cannot create users, and the **Create a New User** button does not appear on the Users page for a Tenant Admin. To bring a new person into a tenant, have a Customer Domain Admin create the user in the domain first; the Tenant Admin can then add that existing user to the tenant and assign a tenant role.
{% endhint %}

1. Navigate to **Settings** > **Tenants and Users** > **Users** and select **Create a New User**. To change an existing user's roles, select the checkbox next to the user and select **Edit** instead.
2. Choose an access level: **System-Level Access**, **Domain-Level Access**, or **Tenant-Level Access**.
3. Depending on the access level chosen:
   * **System-Level Access**: choose the role from the **System Role** dropdown.
   * **Domain-Level Access**: choose **Customer Domain Admin** from the **Domain Role** dropdown.
   * **Tenant-Level Access**: under **Tenant Assignment**, select the checkbox next to one or more tenants, then choose a role for each from its **Roles** dropdown.
4. Select **Create User** (or **Update User** when editing an existing user).

### Using the CLI

{% hint style="warning" %}
**CLI/SDK support**

CLI and SDK support for granular RBAC role assignment has not been validated as thoroughly as the UI flows described above. If you hit unexpected behavior using `pcdctl` for these role assignments, verify the result in the UI or contact Platform9 support.
{% endhint %}

You can also assign granular RBAC roles with `pcdctl`. First, list the available roles and use the exact role name shown in your environment:

```bash
pcdctl role list
```

Assign a system-scoped role, such as **Platform Admin** or **Service Provider Domain Admin**, at system scope:

```bash
pcdctl role add --user <user-id-or-name> --system all "<system-role-name>"
```

Assign **Customer Domain Admin** at domain scope. The grant is inherited by every tenant in the domain:

```bash
pcdctl role add --user <user-id-or-name> --domain <domain-name> --inherited "<customer-domain-admin-role-name>"
```

Assign a tenant-scoped role, such as **Tenant Admin**, **Application User**, or **Tenant User**, to a specific tenant:

```bash
pcdctl role add --user <user-id-or-name> --project <tenant-name> --project-domain <domain-name> "<tenant-role-name>"
```

### From Edit Domain

The domain-level role (**Customer Domain Admin**) can also be assigned to existing users directly from a domain's settings:

1. Navigate to **Settings** > **Tenants and Users** > **Domains**, select the checkbox next to the domain, and select **Edit**.
2. Under **User Assignment**, select the checkbox next to one or more users, then choose a role for each from its **Roles** dropdown.
3. Select **Update Domain**.

## Next Steps

* For the full capability-by-capability breakdown for each of these six roles, see [Granular RBAC Permissions Reference (Beta)](/private-cloud-director/identity-and-multi-tenancy/rbac-roles-and-permissions/granular-rbac-permissions-reference.md).

## Related Pages

* [RBAC Roles and Permissions](/private-cloud-director/identity-and-multi-tenancy/rbac-roles-and-permissions.md): the legacy Admin, Self-Service User, and ReadOnly roles.
* [Domains](/private-cloud-director/identity-and-multi-tenancy/domains.md): how domains contain tenants, users, and groups.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.platform9.com/private-cloud-director/identity-and-multi-tenancy/rbac-roles-and-permissions/granular-rbac-roles.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.