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, you must satisfy the following requirements:

• 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

1. 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]
       connectClusterId:         --- [9c]
       ksqlClusterId:            --- [9d]
     clustersScopeByRegistryName:--- [10]
     kafkaRestClassRef:          --- [11]
       name:                     --- [12]
       namespace:                --- [13]
     kafkaClusterRef:            --- [14]
       name:                     --- [15]
       namespace:                --- [16]
       kind:                     --- [17]
   

   • [1] Required. The identity of a user or group this rolebinding is created for.

   • [2] Required. The principal type. 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 resource type the role binding is applied to. Valid options are Topic, Group, Subject, KsqlCluster, Cluster, TransactionalId, FlinkEnvironment, and FlinkApplication. 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, connectClusterId, cmfId, and flinkEnvironmentId.

     • [9a] Get the Apache 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
       

       On a Confluent Private Cloud multi-tenant Physical Kafka Cluster (PKC), kafkaClusterId can also be a Logical Kafka Cluster (LKC) ID, scoping the role binding to a single LKC. The preceding commands return the PKC ID. To scope to an LKC, use kafkaClusterRef ([14]) instead.

       For information about the TenantAdmin and OrganizationAdmin roles, see Use Predefined RBAC Roles in Confluent Platform.

     • [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>, unless a custom group.id is configured on the Connect CR, in which case use that value instead.

     • [9d] ksqlDB cluster ID is in the following pattern: <namespace>.<ksqldb_cr_name>_ (note the trailing underscore).

   • [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 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.

   • [14] Optional. A direct reference to a Kafka CR, or, on a Confluent Private Cloud multi-tenant PKC, to a LogicalKafkaCluster CR. When it references a LogicalKafkaCluster CR, the role binding is scoped to that single LKC. When it references a Kafka CR, the role binding is scoped to the whole PKC. Use this field instead of kafkaClusterId ([9a]).

     You can’t set kafkaClusterRef together with clustersScopeByRegistryName ([10]) or clustersScopeByIds ([9])’s kafkaClusterId ([9a]). CFK rejects the CR if you do, so an LKC grant can’t be silently over-scoped by combining both mechanisms.

   • [15] Required under kafkaClusterRef ([14]). The name of the Kafka or LogicalKafkaCluster CR.

   • [16] Optional. The namespace of the referenced CR. If omitted, defaults to the namespace of this ConfluentRolebinding CR.

   • [17] Optional. Set to Kafka or LogicalKafkaCluster to disambiguate when a Kafka CR and a LogicalKafkaCluster CR share the same name ([15]) in the namespace. If kind is unset and both exist, CFK fails to reconcile the CR and reports an ambiguous reference error in the CR status.

     For more information, see Manage Tenant Access with RBAC in Confluent Private Cloud.

2. 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, 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. The check only considers ConfluentRolebinding resources that are visible to the operator managing that cluster. A co-owning ConfluentRolebinding on another region’s cluster is not visible. Removing a pattern from a ConfluentRolebinding, or deleting it, can therefore revoke a binding that a ConfluentRolebinding in another region still declares. In MRC, use caution when you remove patterns or delete ConfluentRolebinding resources if the same (principal, role, scope, resourcePattern) is declared on another region’s cluster.

For Confluent for Kubernetes 3.4.0 and later, you can also use the platform.confluent.io/enable-drift-correction annotation to have CFK periodically re-assert role bindings that were revoked or changed outside of the ConfluentRolebinding CR, for example using Control Center or MDS APIs directly. See Annotate Confluent custom resources for details.

When you use the Confluent CLI or other ways to update or delete rolebindings, apply the following annotation to force reconciliation 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

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

• Name

• Status

• Cluster ID

• Principal

• Role

• Resources