Manage Confluent Role Bindings using Confluent for Kubernetes Blueprints

You can declaratively create and manage Confluent Role-Based Access Control (RBAC) on Confluent Platform clusters using Confluent for Kubernetes (CFK) Blueprints.

After you deploy a Confluent Platform with RBAC enabled, use the ConfluentRolebinding custom resource definition (CRD) to create and manage role binding.

For role binding custom resource (CR) examples, see Sample Rolebindings in the example GitHub repo.

Create a role binding

Create a ConfluentRoleBinding CR:

apiVersion: apps.cpc.platform.confluent.io/v1beta1
kind: ConfluentRolebinding
spec:
  principal:                  --- [1]
    type:                     --- [2]
    name:                     --- [3]
  role:                       --- [4]
  resourcePatterns:           --- [5]
    - name:                   --- [6]
      resourceType:           --- [7]
      patternType:            --- [8]
  clustersScopeByIds:         --- [9]
    kafkaClusterId:
    schemaRegistryClusterId:
    ksqlClusterId:
    connectClusterId:
  clustersScopByRegistryName: --- [10]
  kafkaClusterRef:
    name:                     --- [11]
    namespace:                --- [12]

[1] Required. The identity of a user or group this role binding 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.
[5] Qualified resources associated with this role binding.
[6] The name of the resource associated with this role binding.

This setting cannot be updated. When you update this resource name, a new role binding is created.
[7] Required. The type of the resource.
[8] Specify whether the pattern of resource is PREFIXED or LITERAL. The default is LITERAL if not set.
[9] The scope of the cluster id. You can specify a cluster name ([10]) or one scope id among kafkaClusterId, schemaRegistryClusterId, ksqlClusterId, and connectClusterId.

You can retrieve the cluster IDs with the kubectl get command. For example, to get the Kafka cluster ID:
```
kubectl get kafkacluster <cluster_name> -oyaml | grep kafkaClusterId
```
[10] The cluster name registered in the cluster registry, which uniquely identifies the cluster for this role binding.
[11] Required. The name of the Kafka cluster.
[12] The namespace of the Kafka cluster. If omitted, the namespace of this ConfluentRoleBinding CR is used.

The following example shows how a Confluent CLI command to create a role binding is translated to a ConfluentRolebinding CR:

confluent iam rbac role-binding create --principal User:<user-id> \
  --role DeveloperRead --resource Subject:* \
  --kafka-cluster-id <kafka-cluster-id> \
  --schema-registry-cluster-id <schema-registry-group-id>

apiVersion: platform.confluent.io/v1beta1
kind: ConfluentRolebinding
metadata:
  name: internal-schemaregistry-schema-validation
  namespace: <namespace>
spec:
  principal:
    name: <user-id>
    type: user
  clustersScopeByIds:
    schemaRegistryClusterId: <schema-registry-group-id>
    kafkaClusterId: <kafka-cluster-id>
  resourcePatterns:
    name: "*"
    patternType: LITERAL
    resourceType: Subject
  role: DeveloperRead
  kafkaClusterRef:
    name: Kafka

Update a role binding

The spec.principal and the spec.role cannot be updated in a ConfluentRoleBinding CR.

To update a role binding, edit the ConfluentRoleBinding CR and apply the changes with the kubectl apply command.

View the status of a role binding

To see the current status of a role binding, run the following command:

kubectl describe confluentrolebinding.apps <ConfluentRolebinding CR>

Delete a role binding

To delete a role binding, run one of the following commands:

kubectl delete -f <ConfluentRolebinding CR yaml file>

kubectl delete confluentrolebinding.apps <ConfluentRoleBinding name>

View all role bindings

To view all the Confluent role bindings, run the following command:

kubectl get confluentrolebinding.apps