> 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.md).

# RBAC Roles and Permissions

Reference for PCD role-based access control (RBAC): the available roles, what each role can do across resource types, and how roles map from SSO group assignments.

## Overview

<code class="expression">space.vars.product\_name</code> uses role-based access control (RBAC) to determine what actions a user can perform on resources within a tenant (project). Roles are assigned per tenant; a user can have different roles in different tenants.

This page describes the built-in roles, their permissions across the main resource types, and how to assign roles from SSO group mappings.

{% hint style="info" %}
**Granular RBAC (Beta)**

For deployments that need finer-grained delegation than the three built-in roles below (for example, separating platform-wide administration from a service provider's or a single domain's administration), <code class="expression">space.vars.product\_name</code> also offers a six-role Granular RBAC model, currently in beta. See [Granular RBAC Roles (Beta)](/private-cloud-director/identity-and-multi-tenancy/rbac-roles-and-permissions/granular-rbac-roles.md) and [Granular RBAC Permissions Reference (Beta)](/private-cloud-director/identity-and-multi-tenancy/rbac-roles-and-permissions/granular-rbac-permissions-reference.md).
{% endhint %}

## Built-in Roles

<code class="expression">space.vars.product\_acronym</code> provides three built-in roles.

| Role                  | Also Called   | Intended For                                                                                                   |
| --------------------- | ------------- | -------------------------------------------------------------------------------------------------------------- |
| **Admin**             | Administrator | Full control over all resources in the tenant. Typically assigned to infrastructure administrators.            |
| **Self-Service User** | SSU           | Can create and manage their own resources within the tenant. Intended for end users who launch and manage VMs. |
| **ReadOnly**          | Read-Only     | Can view resources but cannot create, modify, or delete them. Intended for auditors and observers.             |

{% hint style="info" %}
**Domain-level vs. tenant-level roles**

Roles can be assigned at either the tenant (project) level or the domain level. A domain-level Admin has administrative access across all tenants in that domain. Tenant-level roles are scoped to a single tenant and do not grant access outside it.
{% endhint %}

## Permissions Matrix

The table below summarizes what each built-in role can do across the main resource types. "Full" means the role can create, read, update, and delete. "View" means read-only access. "Own" means the user can manage resources they created but not those created by others.

| Resource Type                                     | Admin         | Self-Service User | ReadOnly |
| ------------------------------------------------- | ------------- | ----------------- | -------- |
| **Virtual Machines:** create, start, stop, delete | Full          | Own               | View     |
| **Virtual Machines:** migrate, resize, snapshot   | Full          | Own               | View     |
| **Volumes:** create, attach, detach, delete       | Full          | Own               | View     |
| **Volume Snapshots**                              | Full          | Own               | View     |
| **Networks:** create, update, delete              | Full          | None              | View     |
| **Shared Networks:** view and use                 | Full          | View + Use        | View     |
| **Routers:** create, update, delete               | Full          | None              | View     |
| **Security Groups:** create, update, delete       | Full          | Own               | View     |
| **Floating IPs:** allocate, associate, release    | Full          | Own               | View     |
| **Images:** upload, update, delete                | Full          | Own               | View     |
| **Images:** copy to additional storage backends   | Full          | Own               | None     |
| **SSH Key Pairs**                                 | Full          | Own               | View     |
| **Tenants (Projects):** manage membership         | Full          | None              | None     |
| **Users:** invite, assign roles                   | Full          | None              | None     |
| **SAML Groups:** configure                        | Full (domain) | None              | None     |
| **Quota management**                              | Full (domain) | None              | None     |
| **Audit Logs:** view                              | Full          | None              | View     |

### Known Visibility Limitations for ReadOnly and SSU Users

* **Network resources:** ReadOnly users and Self-Service Users can view shared networks but cannot see private networks owned by other users in the same tenant.
* **Images:** Self-Service Users can see public images and images they uploaded. They cannot see private images uploaded by other users.
  * Self-Service Users can upload, update, and delete their own images, and can share an image they own with other tenants in their domain. To share, open the image, select **Edit**, set the **Visibility** field to **Shared**, and choose the tenants to grant access to. The tenant picker lists only the tenants the user belongs to and never the image owner's own tenant.
  * Making an image **Public** is always an Admin-only action. For a Self-Service User, a public image appears as a read-only value they cannot change.
* **Volumes:** Self-Service Users can see and manage only the volumes they created. Volumes created by other users in the same tenant are not visible to them.
* **Cross-domain shared networks:** a shared network created in one domain is not visible to Self-Service Users in another domain. This is a known limitation with no planned fix.

{% hint style="info" %}
**Tip for administrators**

If a user reports that they cannot see an expected resource, first confirm their role assignment in the tenant. If the role is correct and the resource is still not visible, the resource may be owned by a different user account. An Admin in the same tenant can view all resources regardless of ownership.
{% endhint %}

## Assign Roles to Local Users

Role assignments can only be made directly to local users (users created in <code class="expression">space.vars.product\_acronym</code>). SSO users are listed under the **SSO Users** tab on the Users page and are not available for direct role assignment; their roles are inherited from SAML group mappings instead (see [Assign Roles via SSO Group Mappings](#assign-roles-via-sso-group-mappings) below).

To assign a role to a local (non-SSO) user:

1. Log in to <code class="expression">space.vars.product\_acronym</code> as an Admin.
2. Navigate to **Settings** > **Tenants and Users** > **Users**.
3. Select the **Local Users** tab.
4. Select the checkbox next to the user and select **Edit**.
5. Under **Tenant-Level Access**, in the **Tenant Assignment** table, select the checkbox next to the tenant and choose the role from its **Roles** dropdown.
6. Select **Update User**.

You can also use the CLI:

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

## Assign Roles via SSO Group Mappings

When SSO is enabled, roles are not assigned directly to users. Instead, roles are assigned to SAML groups, and users inherit roles based on which IdP group they belong to.

### How it works

1. A user authenticates via SSO.
2. The IdP sends a SAML assertion that includes the user's group membership as an attribute.
3. <code class="expression">space.vars.product\_acronym</code> evaluates the SAML group mappings configured in **Settings** > **Enterprise SSO** > **SAML Groups**.
4. The first matching SAML group mapping determines the user's role and tenant assignments for this session.

### Configure a SAML Group Role Assignment

1. Navigate to **Settings** > **Enterprise SSO** > **SAML Groups**.
2. Select **Add Group** or edit an existing group.
3. Under **Tenants & Roles**, select **Add Role Assignment**.
4. Choose the tenant (project) and the role to assign to members of this group.
5. Select **Save**.

{% hint style="info" %}
**Granular RBAC group role assignment**

This procedure assigns one of the three built-in roles, scoped to a single tenant. For System-Level or Domain-Level access, or to assign one of the six granular RBAC roles to a group, see [Granular RBAC Roles (Beta)](/private-cloud-director/identity-and-multi-tenancy/rbac-roles-and-permissions/granular-rbac-roles.md) instead. This applies to local user groups as well as SAML groups.
{% endhint %}

### Role Precedence with Multiple Matching Groups

If a user belongs to multiple IdP groups and more than one SAML group mapping matches, <code class="expression">space.vars.product\_acronym</code> applies all matching role assignments. The user receives the union of all roles from all matching groups.

**Example:** if a user matches Group A (Admin in tenant-alpha) and Group B (ReadOnly in tenant-beta), the user is an Admin in tenant-alpha and ReadOnly in tenant-beta.

## Next Steps

* For per-IdP SSO setup instructions, see [Enterprise SSO](/private-cloud-director/identity-and-multi-tenancy/enterprise-sso.md).
* To troubleshoot role assignment issues, see [SSO Troubleshooting Guide](/private-cloud-director/identity-and-multi-tenancy/enterprise-sso/sso-troubleshooting.md).
* For application-level authentication with scoped roles, see [Application Credentials](/private-cloud-director/identity-and-multi-tenancy/application-credentials.md).
* For finer-grained delegation with the beta Granular RBAC model, see [Granular RBAC Roles (Beta)](/private-cloud-director/identity-and-multi-tenancy/rbac-roles-and-permissions/granular-rbac-roles.md).


---

# 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.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.