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.


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

Create a rolebinding

  1. Create a ConfluentRoleBinding CR.

    The following is the structure of the CR:

      principal:                  --- [1]
        type:                     --- [2]
        name:                     --- [3]
      role:                       --- [4]
      resourcePatterns:           --- [5]
        - name:                   --- [6]
          resourceType:           --- [7]
          patternType:            --- [8]
      clustersScopeByIds:         --- [9]
      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.

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

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