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

Private Cloud Director 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.

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), Private Cloud Director also offers a six-role Granular RBAC model, currently in beta. See Granular RBAC Roles (Beta) and Granular RBAC Permissions Reference (Beta).

Built-in Roles

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

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.

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.

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.

Assign Roles to Local Users

Role assignments can only be made directly to local users (users created in PCD). 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 below).

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

1. Log in to PCD 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:

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. PCD 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, PCD 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.
• To troubleshoot role assignment issues, see SSO Troubleshooting Guide.
• For application-level authentication with scoped roles, see Application Credentials.
• For finer-grained delegation with the beta Granular RBAC model, see Granular RBAC Roles (Beta).