Granular RBAC Roles (Beta)

Reference for PCD's Granular Role-Based Access Control (Beta): the six administrative and user roles, their scope, and how they relate to the built-in Admin, Self-Service User, and ReadOnly roles.

Overview

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.

In addition to the three built-in roles described in RBAC Roles and Permissions, Private Cloud Director 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 built-in role set provides — for example, separating platform-wide infrastructure administration from a service provider's customer-facing administration, or from a single customer domain's own administration.

Granular RBAC is additive: it does not replace the built-in Admin, Self-Service User, and ReadOnly roles. A tenant can continue to use the built-in roles, adopt the granular roles, or use both together depending on how access needs to be delegated.

Self-Service User role names

The granular RBAC role set and the built-in role set both include a role named Self-Service User. They are separate roles. In the UI, use the granular RBAC role option, shown with the granular/legacy distinction in the role selector, when following this page. Do not assume that selecting the built-in or legacy Self-Service User role grants the same permissions shown in the granular RBAC permissions reference.

The Six Roles

Role	Scope	Intended For
Platform Admin (Platform Owner)	System (cross-cloud)	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 (cross-cloud, provider-level)	Administers infrastructure and delegation across all customer domains. This role is system-scoped and cannot be limited to selected customer domains.
Customer Domain Admin	Domain	Administrative control over the users, groups, and role bindings of a single customer domain, and over the tenants already in it, without cross-domain or platform-infrastructure access. Creating, renaming, and deleting tenants is reserved for the system-scoped roles. Intended for a domain's own administrators.
Tenant Admin	Project (tenant)	Full control over resources within a single tenant, plus tenant-scoped role management: adding existing users from the tenant's domain to the tenant, assigning and removing tenant roles, and updating existing users in its domain. Cannot create users; that is a domain-level action. Intended for tenant-level administrators.
Self-Service User (SSU, granular RBAC)	Project (tenant), mostly own resources	Can create and manage their own compute, storage, and networking resources within a tenant. This is distinct from the built-in or legacy Self-Service User role.
Tenant User (TU)	Project (tenant), mostly read-only	Primarily read-only visibility into tenant resources, with self-service access to their own SSH keypairs, VM console, and security-group membership on their own VMs. Intended for users who need visibility without broad management rights.

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.

How this relates to the built-in roles

Tenant Admin and the granular RBAC Self-Service User correspond closely to the built-in Admin and built-in Self-Service User roles at the tenant level, but they are separate role definitions with different permission details. Tenant User is similar in spirit to the built-in ReadOnly role. Platform Admin, Service Provider Domain Admin, and Customer Domain Admin have no equivalent in the built-in role set — they exist to separate platform, service-provider, and domain-level administration, which the built-in roles do not distinguish.

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.

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, Self-Service User (granular RBAC), Tenant User

From Create User

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.

1. Navigate to Settings > Tenants and Users > Users, and select Create a New User (or edit an existing user).
2. Choose an access level: System-Level Access, Domain-Level Access, or Tenant-Level Access.
3. Depending on the access level chosen:

   • System-Level or Domain-Level: select the role from the dropdown shown.
   • Tenant-Level: under Tenant Assignment, select the checkbox next to one or more tenants, then choose a role for each from its Roles dropdown. For Self-Service User access in this model, select the granular RBAC Self-Service User option, not the built-in or legacy Self-Service User option.
4. Select Create User (or Save).

Using the CLI

CLI/SDK support

CLI and SDK support for granular RBAC role assignment has not been validated as thoroughly as the UI flows described above. Some operations may not be fully supported. If you hit unexpected behavior using pcdctl for these role assignments, verify the result in the UI or contact Platform9 support.

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

pcdctl role list

Assign a system-scoped role, such as Platform Admin or Service Provider Domain Admin, without a project or domain scope:

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

Assign Customer Domain Admin at domain scope:

pcdctl role add --user <user-id-or-name> --role "<customer-domain-admin-role-name>" \
  --os-user-domain-name <domain-name>

Assign a tenant-scoped role, such as Tenant Admin, granular RBAC Self-Service User, or Tenant User, to a specific tenant:

pcdctl role add --user <user-id-or-name> --role "<tenant-role-name>" \
  --os-project-name <tenant-name> \
  --os-project-domain-name <domain-name>

For Service Provider Domain Admin, do not add a customer-domain filter. It is system-scoped and grants access across all customer domains. For Self-Service User, select the granular RBAC role name from pcdctl role list, not the built-in or legacy Self-Service User role.

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 > Domains, and select a domain to 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.

Related Pages

• RBAC Roles and Permissions: the built-in Admin, Self-Service User, and ReadOnly roles.
• Domains: how domains contain tenants, users, and groups.

Next Steps

• For the full capability-by-capability breakdown for each of these six roles, see Granular RBAC Permissions Reference (Beta).