<a id="multi-tenancy-manage-tenant-access"></a>

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


<a id="multi-tenancy-manage-access-scope"></a>

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

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

```bash
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:

```yaml
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:

```bash
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.

<a id="multi-tenancy-manage-access-revoke"></a>

## Revoke administrative access

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

1. List the role bindings and find each one that names the person:
   ```bash
   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
   ```
2. Delete each of the person’s `ConfluentRolebinding` CRs:
   ```bash
   kubectl delete confluentrolebinding <tenant-admin-binding-name> -n <your-namespace>
   ```
3. 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:

```properties
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](../../security/authorization/ldap/configure.md#configure-ldap-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.

## Related content

- Onboard an LKC to a Multi-Tenant Physical Kafka Cluster
- Onboard a Developer
- Monitor and Manage Per-LKC Resource Quotas
- [Use Predefined RBAC Roles in Confluent Platform](../../security/authorization/rbac/rbac-predefined-roles.md#rbac-predefined-roles)
- [Role-Based Access Control for Confluent Platform Quick Start](../../security/authorization/rbac/rbac-cli-quickstart.md#rbac-cli-quickstart)
- [Confluent Metadata API Reference for Confluent Platform](../../security/authorization/rbac/mds-api.md#mds-api)