> 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

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

## 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          | None              | View     |
| **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.
* **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.

{% 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

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 & Users** > **Users**.
3. Select the user.
4. Under **Role Assignments**, select **Add Role Assignment**.
5. Choose the tenant and role.
6. Select **Save**.

You can also use the CLI:

```bash
pcdctl role add --user <user-id> --role <role-name> \
  --os-project-name <tenant-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**.

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


---

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

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

The question should be specific, self-contained, and written in natural language.
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.