Manage Tenant Access with RBAC

Manage role-based access control (RBAC) across a multi-tenant Physical Kafka Cluster (PKC) in Confluent Private Cloud. Platform operators and TenantAdmin users perform these tasks regularly after they onboard a tenant.

Prerequisites

Before you begin, ensure you have the following:

A multi-tenant PKC with at least one provisioned Logical Kafka Cluster (LKC). For more information, see the Deploy a Multi-Tenant Physical Kafka Cluster page and the Onboard an LKC page.
A KafkaRestClass configured in the namespace where you apply ConfluentRolebinding custom resources (CRs). Confluent for Kubernetes (CFK) uses the KafkaRestClass to authenticate to Metadata Service (MDS) when it applies role bindings. Name it default, or set kafkaRestClassRef on each ConfluentRolebinding CR.
An existing identity for everyone you grant access to. Identity can be one of the following:
- A service account in the shared identity provider (IdP) of the PKC
- An existing client certificate for mutual TLS (mTLS) authentication
- An existing group in the shared IdP of the PKC, for group-based role bindings
Confluent Platform or Confluent Private Cloud 8.4 or later, to use group-based role bindings. On an earlier release, group-based role bindings have no effect.
Familiarity with the OrganizationAdmin, TenantAdmin, DeveloperRead, DeveloperWrite, and DeveloperManage roles. For more information, see the Roles and responsibilities section of the Multi-Tenancy Overview page.

Scope role bindings to the tenant’s Logical Kafka Cluster

Every ConfluentRolebinding CR that scopes to a tenant’s resources must set spec.kafkaClusterRef.kind to LogicalKafkaCluster and spec.kafkaClusterRef.name to that tenant’s LKC CR name, not the PKC’s Kafka CR.

Caution

You can’t change kafkaClusterRef after you create a ConfluentRolebinding CR. If a CR sets kafkaClusterRef.kind to Kafka instead of LogicalKafkaCluster, the role binding applies to matching resources in every LKC on the PKC, not only the tenant’s LKC. Delete the CR and create a replacement with the correct reference.

To find role bindings that point to the wrong cluster, list the cluster that each binding resolves to:

kubectl get confluentrolebinding -n <your-namespace> -o custom-columns=NAME:.metadata.name,KIND:.status.resolvedClusterRef.kind,CLUSTER:.status.resolvedClusterRef.name

Delegate administrative access to additional people

When a platform operator onboards a tenant, they assign the TenantAdmin role to the tenant’s first administrator. To delegate administrative access to other people on the same tenant, such as a backup administrator or a second team lead, create an additional ConfluentRolebinding CR, scoped to the same LKC:

apiVersion: platform.confluent.io/v1beta1
kind: ConfluentRolebinding
metadata:
  name: <tenant-admin-binding-name>
  namespace: <your-namespace>
spec:
  principal:
    type: user
    name: <additional-admin-identity>
  role: TenantAdmin
  kafkaClusterRef:
    kind: LogicalKafkaCluster
    name: <lkc-name>

Save the configuration to a file, such as additional-tenant-admin.yaml, and apply it:

kubectl apply -f additional-tenant-admin.yaml

Note

You can grant roles on an LKC in two ways:

Through a ConfluentRolebinding CR. CFK applies the role binding with the identity of the KafkaRestClass that the CR uses, not with your own. That identity must be allowed to grant the role on the LKC. You also need Kubernetes permissions on the ConfluentRolebinding resource in that namespace, so limit those permissions to people who should be able to grant roles.
Directly through the Metadata Service (MDS) API. A principal that holds the TenantAdmin role on an LKC can create role bindings on that LKC. The role can’t create role bindings at the PKC scope or on another LKC.

Revoke administrative access

To revoke a person’s administrative access, remove every way they hold the TenantAdmin role:

List the role bindings and find each one that names the person:

kubectl get confluentrolebinding -n <your-namespace> -o custom-columns=NAME:.metadata.name,PRINCIPAL:.spec.principal.name,TYPE:.spec.principal.type,ROLE:.spec.role,LKC:.spec.kafkaClusterRef.name

Delete each of the person’s ConfluentRolebinding CRs:

kubectl delete confluentrolebinding <tenant-admin-binding-name> -n <your-namespace>

If a group holds the TenantAdmin role on the LKC, remove the person from that group in your identity provider. Deleting their own binding doesn’t remove access they receive through a group.

Deleting a ConfluentRolebinding CR doesn’t affect bindings that you created outside CFK, such as with the Confluent CLI or the Metadata Service (MDS) API. Remove those with the tool you used to create them.

Use group-based role bindings

When multiTenant.enabled is true on the Kafka CR, CFK automatically sets the broker property that group-based role bindings depend on. You don’t need to set it yourself. If you override this property in configOverrides, keep both values:

confluent.authorizer.access.rule.providers=MULTI_TENANT,CPC_RBAC

For Metadata Service (MDS) to resolve group membership, the LDAP configurations on the Kafka CR must also include the group search settings: groupSearchBase, groupObjectClass, groupNameAttribute, groupMemberAttribute, and groupMemberAttributePattern. The pattern must match how your directory returns member distinguished names (DNs), including case. For the settings, see Configure LDAP Group-Based Authorization.

Bind a role to a group the same way you bind one to a user or service account: set spec.principal.type to group and spec.principal.name to the group’s name.

View tenant-scoped resources in Confluent Control Center

Confluent Control Center applies its standard RBAC-based visibility filter to tenant resources. A person sees only the clusters that their role bindings grant them access to. Confluent Control Center displays a tenant’s LKC like any other Apache Kafka® cluster, scoped to that LKC’s own ID.