Configure Confluent Role Based Access Control (RBAC) with Confluent for Kubernetes
Confluent for Kubernetes (CFK) supports Role-Based Access Control (RBAC). RBAC is powered by Confluent’s Metadata Service (MDS), which integrates with an LDAP server and acts as the central authority for authorization and authentication data. RBAC leverages role bindings to determine which users and groups can access specific resources and what actions the users can perform on those resources.
Confluent provides audit logs, that record the runtime decisions of the permission checks that occur as users/applications attempt to take actions that are protected by ACLs and RBAC.
There are a set of principals and role bindings required for the Confluent components to function, and those are automatically generated when CFK is deployed.
Note
RBAC with CFK can be enabled only for new installations in ZooKeeper-based deployments:
You cannot enable RBAC in KRaft-based deployments.
You cannot upgrade an existing cluster and enable it with RBAC.
When you deploy Confluent Platform with RBAC enabled, CFK automates the security setup. Here’s the end state architecture:

Based on the components and features you use, you need to configure the following additional role bindings:
Requirements
The following are the requirements for enabling and using RBAC with CFK:
You must have an LDAP server that Confluent Platform can use for authentication.
Currently, CFK only supports the
GROUPS
LDAP search mode. The search mode indicates if the user-to-group mapping is retrieved by searching for group or user entries. If you need to use theUSERS
search mode, specify using theconfigOverrides
setting in the Kafka CR as below:spec: configOverrides: server: - ldap.search.mode=USERS
See Sample Configuration for User-Based Search for more information.
Confluent REST service is automatically enabled for RBAC and cannot be disabled when RBAC is enabled.
Use the Kafka bootstrap endpoint (same as the MDS endpoint) to access Confluent REST API.
You must create the user principals in LDAP that will be used by Confluent Platform components. These are the default user principals:
Kafka:
kafka
/kafka-secret
Confluent REST API:
erp
/erp-secret
Confluent Control Center (Legacy):
c3
/c3-secret
ksqlDB:
ksql
/ksql-secret
Schema Registry:
sr
/sr-secret
Replicator:
replicator
/replicator-secret
Connect:
connect
/connect-secret
Create the LDAP user/password for a user who has a minimum of LDAP read-only permissions to allow Metadata Service (MDS) to query LDAP about other users. For example, you’d create a user
mds
with passwordDeveloper!
Create a user for the Admin REST service in LDAP and provide the username and password.
Configure RBAC with CFK
The comprehensive security tutorial walks you through an end-to-end setup of role-based access control (RBAC) for Confluent with CFK. We recommend you take the CustomResource spec and the steps outlined in the scenario as a starting point and customize for your environment.
Enable RBAC for Kafka
To configure and deploy Kafka with the Confluent RBAC:
Specify the MDS and LDAP settings in your Kafka Custom Resource (CR):
kind: Kafka spec: services: mds: --- [1] tokenKeyPair: --- [2] provider: type: ldap --- [3] ldap: --- [4] address: ldap://ldap.confluent.svc.cluster.local:389 authentication: type: simple simple: secretRef: credential configurations: groupNameAttribute: cn groupObjectClass: group groupMemberAttribute: member groupMemberAttributePattern: CN=(.*),DC=test,DC=com groupSearchBase: dc=test,dc=com userNameAttribute: cn userMemberOfAttributePattern: CN=(.*),DC=test,DC=com userObjectClass: organizationalRole userSearchBase: dc=test,dc=com
[1] Required.
[2] Required. The token key pair to authenticate to MDS.
For details, see MDS authentication token keys.
[3] Required for LDAP.
[4] Required. A few examples properties are given above.
Specify the RBAC settings in your Kafka Custom Resource (CR):
kind: Kafka spec: authorization: type: rbac --- [1] superUsers: --- [2] dependencies: kafkaRest: --- [3] authentication: type: bearer --- [4] bearer: secretRef: --- [5] directoryPathInContainer: --- [6]
[1] Required.
[2] Required. The super users to be given the admin privilege on the Kafka cluster.
These users have no access to resources in other Confluent Platform clusters unless they also configured with specific role bindings on the clusters.
This list is in the
User:<user-name>
format. For example:superUsers: - "User:kafka" - "User:testadmin"
[3] Required. The REST client configuration for MDS when RBAC is enabled.
[4] Required.
[5] or [6] Required.
When RBAC is enabled (
spec.authorization.type: rbac
), CFK always uses the Bearer authentication for Confluent components, ignoring thespec.authentication
setting. It is not possible to set the component authentication type to mTLS when RBAC is enabled.[5] The username and password are loaded through secretRef.
The expected key is
bearer.txt
.The value for the key is:
username=<username> password=<password>
[6] Provide the path where required credentials are injected by Vault. See [5] for the expected key and the value.
Configure the Admin REST Class CR.
You need to use the
bearer
authentication for the Admin Rest Class as shown below.For the rest of the configuration details for the Admin REST Class, see Manage Confluent Admin REST Class using Confluent for Kubernetes.
kind: KafkaRestClass metadata: name: --- [1] namespace: spec: kafkaRest: authentication: type: bearer --- [2] bearer: secretRef: --- [3] directoryPathInContainer: --- [4]
[1] Optional. If not specified,
default
is used as the name of this REST class.[2] Required for RBAC.
[3] or [4] Required.
[3] The username and password are loaded through secretRef.
The expected key is
bearer.txt
.The value for the key is:
username=<username> password=<password>
[4] Provide the path where required credentials are injected by Vault. See [2] for the expected key and the value.
When RBAC is enabled (
spec.authorization.type: rbac
), CFK always uses the Bearer authentication for Confluent components, ignoring thespec.authentication
setting. It is not possible to set the component authentication type to mTLS when RBAC is enabled.
MDS authentication token keys
To sign the token generated by the MDS server, you can use the PKCS#1 or PKCS#8 PEM key format. When using PKCS#8, the private key can be unencrypted or encrypted with a passphrase.
To provide the MDS token keys:
Create a PEM key pair as described in Create a PEM key pair for MDS.
If using an encrypted private key:
Create a passphrase file with the name,
mdsTokenKeyPassphrase.txt
.In the
mdsTokenKeyPassphrase.txt
file, add the key-value pair with themdsTokenKeyPassphrase
key and the passphrase that the private key was encrypted with:
mdsTokenKeyPassphrase=<passphrase>
Add the public key and the token key pair to a secret or inject it in a directory path in the container using Vault.
To use an encrypted private key, add the passphrase value to the secret or the directory path in the container, as well.
An example command to create a secret with an unencrypted private key:
kubectl create secret generic mds-token \ --from-file=mdsPublicKey.pem=mds-publickey.txt \ --from-file=mdsTokenKeyPair.pem=mds-tokenkeypair.txt \ --namespace confluent
An example command to create a secret with an encrypted private key:
kubectl create secret generic mds-token \ --from-file=mdsPublicKey.pem=mds-publickey.txt \ --from-file=mdsTokenKeyPair.pem=mds-tokenkeypair.txt \ --from-file=mdsTokenKeyPassphrase.pem=mdsTokenKeyPassphrase.txt \ --namespace confluent
In the Kafka CR, specify the token key pair to authenticate to MDS:
kind: Kafka spec: services: mds: tokenKeyPair: secretRef: --- [1] directoryPathInContainer: --- [2] encryptedTokenKey: --- [3]
[1] The name of the Kubernetes secret that contains the public key and the token key pair to sign the token generated by the MDS server.
[2] The directory path in the container where the required public key and the token key pair are injected by Vault.
[3] Optional. Set to
true
to use an encrypted private key. The default value isfalse
.
Enable RBAC for other Confluent Platform components
To configure and deploy other non-Kafka components with the Confluent RBAC:
Specify the settings in the component CR:
spec: authorization: type: rbac --- [1] kafkaRestClassRef: --- [2] name: default dependencies: mds: endpoint: --- [3] tokenKeyPair: --- [4] secretRef: directoryPathInContainer authentication: type: bearer --- [5] bearer: secretRef: --- [6] directoryPathInContainer: --- [7]
[1] Required for RBAC.
[2] If
kafkaRestClassRef
is not configured, the kafkaRestClass with the name,default
, in the current namespace is used.[3] Required. MDS endpoint.
[4] Required. The token key pair and the public key to authenticate to the MDS. Use
secretRef
ordirectoryPathInContainer
to specify.You need to add the public key and the token key pair to the secret or directoryPathInContainer. For details, see Create a PEM key pair for MDS.
An example command to create a secret is:
kubectl create secret generic mds-token \ --from-file=mdsPublicKey.pem=mds-publickey.txt \ --from-file=mdsTokenKeyPair.pem=mds-tokenkeypair.txt \ --namespace confluent
[5] Required.
[6] or [7] Required.
When RBAC is enabled (
spec.authorization.type: rbac
), CFK always uses the Bearer authentication for Confluent components, ignoring thespec.authentication
setting. It is not possible to set the component authentication type to mTLS when RBAC is enabled.[6] The username and password are loaded through secretRef.
The expected key is
bearer.txt
.The value for the key is:
username=<username> password=<password>
[7] Provide the path where required credentials are injected by Vault. See [2] for the expected key and the value.
Use an existing Admin REST Class or create a new Admin REST Class CR as described in the previous section.
Automated creation of role bindings for Confluent Platform component principals
CFK automatically creates all required role bindings for Confluent Platform components as ConfluentRoleBinding custom resources (CRs).
Review the role bindings created by CFK:
kubectl get confluentrolebinding
Grant role to Kafka user to access Schema Registry
Use the following ConfluentRolebinding CR to create the required role binding to access Schema Registry:
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
Grant roles to a Confluent Control Center (Legacy) user to administer Confluent Platform
Control Center (Legacy) users require separate roles for each Confluent Platform component and resource they wish to view and administer in the Control Center (Legacy) UI. Grant explicit permissions to the users as shown below.
In the following example, the testadmin
principal is used as a Control Center (Legacy) UI
user.
Grant permission to view and administer Confluent Platform components
The rolebinding CRs in the examples GitHub repo specifies the permissions needed in CFK. Create the rolebindings with the following command:
kubectl apply -f \
https://raw.githubusercontent.com/confluentinc/confluent-kubernetes-examples/master/security/production-secure-deploy/controlcenter-testadmin-rolebindings.yaml
Check the roles created:
kubectl get confluentrolebinding
Troubleshooting: Verify MDS configuration
Log into MDS to verify the correct configuration and to get the Kafka cluster ID. You need the Kafka cluster ID for component role bindings.
Replace https://<mds_endpoint>
in the below commands with the value you set
in the spec.dependencies.mds.endpoint
in the Kafka CR.
Log into MDS as the Kafka super user as below:
confluent login \ --url https://<mds_endpoint> \ --ca-cert-path <path-to-cacerts.pem>
You need to pass the
--ca-cert-path
flag if:You have configured MDS to serve HTTPS traffic (
kafka.spec.dependencies.mds.tls.enabled: true
).The CA used to issue the MDS certificates is not trusted by system where you are running these commands.
Provide the Kafka username and password when prompted, in this example,
kafka
andkafka-secret
.You get a response to confirm a successful login.
Verify that the advertised listeners are correctly configured using the following command:
curl -ik \ -u '<kafka-user>:<kafka-user-password>' \ https://<mds_endpoint>/security/1.0/activenodes/https
Get the Kafka cluster ID using one of the following commands:
confluent cluster describe --url https://<mds_endpoint>
curl -ik \ https://<mds_endpoint>/v1/metadata/id