Setting Up Kubernetes RBAC for SSO User Groups on PCD Workload Clusters

Problem

When SSO users access a PCD workload cluster, they need Kubernetes RBAC bindings that map their SSO group memberships to cluster permissions. This guide shows how to grant access to SSO groups using Kubernetes ClusterRoleBinding or RoleBinding resources.

Environment

• Private Cloud Director Kubernetes – v2026.1 and Higher

Prerequisites

• A workload cluster created in PCD

• SSO configured in your PCD deployment

• kubectl access to the workload cluster (or access to the PCD UI RBAC section)

Default ClusterRoles

Every PCD workload cluster ships with the standard Kubernetes ClusterRoles that you can reference in your bindings:

ClusterRole	Permissions
cluster-admin	Full access to all resources in all namespaces
admin	Read/write access to most resources in a namespace (excludes resource quotas and the namespace itself)
edit	Read/write access to common workload resources (Deployments, Services, ConfigMaps, etc.)
view	Read-only access to most resources in a namespace

Default Tenant RBAC

PCD automatically creates four ClusterRoleBindings in each workload cluster for the tenant that owns it:

ClusterRoleBinding	ClusterRole	Group
kaapi-cluster-admin-binding	cluster-admin	<du>-<domain>-<tenant>-admin
kaapi-cluster-member-binding	cluster-admin	<du>-<domain>-<tenant>-member
kaapi-cluster-reader-binding	view	<du>-<domain>-<tenant>-reader
kaapi-node-reader-binding	kaapi-node-reader	<du>-<domain>-<tenant>-reader

Group names follow the pattern <du>-<domain>-<tenant>-<role>, where <du> is the deployment unit name (e.g. mydu), <domain> is the domain name in the PCD (e.g. default), <tenant> is the tenant name, and <role> is one of admin, member, or reader.

You can inspect your own groups by running:

kubectl auth whoami -o yaml

Users assigned to the tenant in PCD automatically receive access through these bindings based on their tenant role. No extra steps are required for tenant users.

Granting Access to Additional SSO Groups

If you need to grant cluster access to SSO users who are not part of the owning tenant, create a binding that references their SSO group name.

There are two types of groups you may encounter:

• PCD tenant groups — Automatically created by PCD, following the naming pattern <du>-<domain>-<tenant>-<role> (e.g. mydu-default-app-admin). Use these when granting access to users who already belong to a different PCD tenant.

• External SSO groups — Defined in your identity provider (Okta, Azure AD, etc.) and passed through in the token's groups claim (e.g. app-team). Use these when granting access to users managed outside of PCD's tenant model.

The examples below use an external SSO group called app-team.

Option A: Cluster-wide access via ClusterRoleBinding

Grant the SSO group app-team read-only access across the entire cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: app-team-view
subjects:
- kind: Group
  name: app-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f app-team-view.yaml

Option B: Namespace-scoped access via RoleBinding

Grant the SSO group app-team edit access only in the app namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-team-edit
  namespace: app
subjects:
- kind: Group
  name: app-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f app-team-edit.yaml

Note: You can reference a ClusterRole in a RoleBinding. The permissions will be scoped to the RoleBinding's namespace.

Option C: Using the PCD UI

1. Navigate to Kubernetes > RBAC > ClusterRoleBindings

2. Click Add ClusterRoleBinding

3. Select the target cluster and the desired ClusterRole

4. Select the SSO group(s) to bind

5. Click Add ClusterRoleBinding

Verifying Access

After creating the binding, the SSO user can verify their permissions:

kubectl auth can-i list pods --namespace app