# Manage RBAC for Confluent Platform Using Confluent for Kubernetes Confluent for Kubernetes (CFK) provides the ConfluentRolebinding custom resource definition (CRD). With the ConfluentRolebinding CRD, you can declaratively create and manage [Confluent Role-Based Access Control (RBAC)](https://docs.confluent.io/platform/current/security/rbac/index.html) for users and groups as custom resources (CRs) in Kubernetes. For rolebinding custom resource examples, see [Sample Rolebindings](https://github.com/confluentinc/confluent-kubernetes-examples/tree/master/security/production-secure-deploy/example-rolebindings) in GitHub. ## Requirements Before you create rolebindings using ConfluentRolebinding CRs, the following requirements must be satisfied: * [Deploy the Confluent clusters with RBAC](co-rbac.md#co-rbac). * [Set up the Confluent Admin REST Class](co-manage-rest-api.md#co-manage-rest-api). Confluent rolebindings are created and managed using Admin REST APIs, and the REST Class must be running on the Confluent Platform cluster. ## Create a rolebinding 1. Create a `ConfluentRolebinding` CR. The following is the structure of the CR: ```yaml kind: ConfluentRolebinding metadata: name: namespace: spec: principal: --- [1] type: --- [2] name: --- [3] role: --- [4] resourcePatterns: --- [5] - name: --- [6] resourceType: --- [7] patternType: --- [8] clustersScopeByIds: --- [9] kafkaClusterId: --- [9a] schemaRegistryClusterId: --- [9b] connectClusterId: --- [9c] ksqlClusterId: --- [9d] clustersScopeByRegistryName:--- [10] kafkaRestClassRef: --- [11] name: --- [12] namespace: --- [13] ``` * [1] Required. The identity of a user or group this rolebinding is created for. * [2] Required. The type of the principal. Set it to `user` or `group`. * [3] Required. The name of the principal. * [4] Required. Predefined role name. For the predefined roles you can use, refer to [Confluent RBAC Predefined Roles](https://docs.confluent.io/platform/current/security/rbac/rbac-predefined-roles.html). * [5] Optional. Qualified resources associated with this rolebinding. * [6] Required. The name of the resource associated with this rolebinding. This setting cannot be updated. When you update this resource name, a new rolebinding is created. * [7] Required. The type of resource the role binding is applied to. Valid options are `Topic`, `Group`, `Subject`, `KsqlCluster`, `Cluster`, and `TransactionalId`. For more information about the RBAC resource, see [Authorization using Role-Based Access Control](https://docs.confluent.io/platform/current/security/rbac/index.html#terminology). * [8] Optional. Specify whether the pattern of resource is `PREFIXED` or `LITERAL`. The default is `LITERAL` if not set. * [9] Optional. The scope of the cluster id. You can specify a cluster name ([10]) or one scope id among `kafkaClusterId`, `schemaRegistryClusterId`, `ksqlClusterId`, and `connectClusterId`. * [9a] Get the Kafka cluster ID using one of the following commands: ```bash confluent cluster describe --url https:// ``` ```bash curl -ik https:///v1/metadata/id ``` * [9b] Schema Registry cluster id is in the following pattern: `id__` * [9c] Connect cluster id is in the following pattern: `.` * [9d] ksqlDB cluster id is in the following pattern: `.` * [10] Optional. The cluster name registered in the [cluster registry](https://docs.confluent.io/platform/current/security/cluster-registry.html#cluster-registry-and-mds), which uniquely identifies the cluster for this rolebinding. * [11] Optional. The KafkaRestClass CR that defines configurations for the Confluent REST Class. If it is not configured, the default KafkaRestClass is used. * [12] Required under `kafkaRestClassRef` ([11]). The name of the KafkaRestClass CR. * [13] Optional. If omitted, the same namespace of this `ConfluentRolebinding` CR is used. 2. Apply the ConfluentRolebinding CR: ```bash kubectl apply -f ``` The following example shows how a Confluent CLI command to create a role binding is translated to a ConfluentRolebinding CR: ```bash confluent iam rbac role-binding create --principal User: \ --role DeveloperRead --resource Subject:* \ --kafka-cluster-id \ --schema-registry-cluster-id ``` ```yaml apiVersion: platform.confluent.io/v1beta1 kind: ConfluentRolebinding metadata: name: internal-schemaregistry-schema-validation namespace: spec: principal: name: type: user clustersScopeByIds: schemaRegistryClusterId: kafkaClusterId: resourcePatterns: name: "*" patternType: LITERAL resourceType: Subject role: DeveloperRead ``` ## Update a rolebinding Principal, Role, and Scope cannot be updated in a `ConfluentRolebinding` CR. To update a rolebinding, edit the `ConfluentRolebinding` CR and apply the changes with the `kubectl apply` command. #### NOTE Starting in CFK 3.3.0, removing a resource pattern or deleting a `ConfluentRolebinding` revokes its role binding in Metadata Service (MDS), unless a live sibling `ConfluentRolebinding` still co-owns the same `(principal, role, scope, resourcePattern)`. In Multi-Region Cluster (MRC) deployments, this co-ownership check has a known limitation. For details, see [the 3.3.0 release notes](release-notes.md#co-mrc-rolebinding-limitation). When you use the Confluent CLI or other ways to update/delete rolebindings, apply the following annotation to force reconcile with the corresponding `ConfluentRolebinding` CR: ```bash kubectl annotate confluentrolebinding platform.confluent.io/force-reconcile=true ``` ## View status of a rolebinding To see the current status of a rolebinding, run the following command: ```bash kubectl describe confluentrolebinding ``` ## Delete a rolebinding To delete a rolebinding, run the following command: ```bash kubectl delete -f ``` ## View all rolebindings To view all the Confluent rolebindings, run the following command: ```bash kubectl get cfrb/confluentrolebinding ``` The output lists all Confluent rolebindings with the below information for each rolebinding: * Name * Status * Cluster id * Principal * Role * Resources