Manage Confluent Role-based Access Control¶

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

Confluent rolebindings are created and managed using Admin REST APIs, and Admin REST APIs must be running on the Confluent Platform cluster.

Create a rolebinding¶

Create a ConfluentRoleBinding CR.

The following is the structure of the CR:
```
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]
  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 the resource.
- [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.
- [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 API. 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>

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