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) for users and groups as custom resources (CRs) in Kubernetes.

For rolebinding custom resource examples, see Sample Rolebindings in GitHub.

Requirements¶

Before you create rolebindings using ConfluentRolebinding CRs, the following requirements must be satisfied:

Deploy the Confluent clusters with RBAC.
Set up the Confluent Admin REST Class.

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¶

Create a ConfluentRoleBinding CR.

The following is the structure of the CR:
```
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]
    ksqlClusterId:            --- [9c]
    connectClusterId:         --- [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.
- [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.
- [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:
    confluent cluster describe --url https://<kafka_bootstrap_endpoint>
    curl -ik https://<mds_endpoint>/v1/metadata/id
  - [9b] Schema Registry cluster id is in the following pattern: id_<SR-CR-name>_<namespace>
  - [9c] Connect cluster id is in the following pattern: <namespace>.<Connect-CR-name>
  - [9d] ksqlDB cluster id is in the following pattern: <namespace>.<ksqldb-CR-name>
- [10] Optional. The cluster name registered in the cluster registry, 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.

Apply the ConfluentRolebinding CR:

kubectl apply -f <ConfluentRolebinding CR>

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

Update a rolebinding¶

Principal and Role cannot be updated in a ConfluentRoleBinding CR.

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

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:

kubectl annotate confluentrolebinding <name> platform.confluent.io/force-reconcile=true

View status of a rolebinding¶

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

kubectl describe confluentrolebinding <ConfluentRolebinding CR>

Delete a rolebinding¶

To delete a rolebinding, run the following command:

kubectl delete -f <ConfluentRolebinding CR>

View all rolebindings¶

To view all the Confluent rolebindings, run the following command:

kubectl get cfrb/confluentrolebinding

The output lists all Confluent rolebindings with the below information for each rolebinding:

Name
Status
Cluster id
Principal
Role
Resources