Configure Simple ACLs with Confluent for Kubernetes¶
To deploy Kafka with the Access Control Lists authorization, specify the settings in your Kafka CustomResource:
kind: Kafka spec: authorization: type: simple ---  superUsers:
-  Required. Set it to
simple. Kafka will be configured to use simple authorization (ZooKeeper-backed ACLs) when configured.
mTLS authentication: Extracting principal from certificate¶
When mTLS authentication is enabled, Confluent Platform determines the identity of the
authenticated principal via data extracted from the client certificate. The
Subject section of the certificate is will be used to determine the
For example, with the following certificate’s subject (
C=US, ST=CA, L=Palo
Alto), the username will be extracted as
Certificate: Data: Version: 3 (0x2) Serial Number: omitted... Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Palo Alto, L=CA, O=Company, OU=Engineering, CN=TestCA Validity Not Before: Mar 28 16:37:00 2019 GMT Not After : Mar 26 16:37:00 2024 GMT Subject: C=US, ST=CA, L=Palo Alto Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus:
User:ANONYMOUS is the default user for internal clients and inter-broker
When Kafka is configured with mTLS authentication, in addition to
User:ANONYMOUS, the cert user name is required.
Typically, you will have many different users and clients of Confluent Platform. In some cases, you may have shared client certificates across multiple users/clients, but the best practice is to issue unique client certificates for each user and certificate, and each certificate should have a unique subject/username. For each user/client, you must decide what they should be authorized to access within Confluent Platform, and ensure that the corresponding ACLs have been created for the subject/username of their corresponding client certificates. Follow the instructions in Authorization using ACLs to enable ACL authorization for Kafka objects.