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 --- [1]
superUsers:
- [1] 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 used to determine the
username.
For example, with the following certificate’s subject (C=US, ST=CA, L=Palo
Alto
), the username will be extracted as User:L=Palo Alto,ST=CA,C=US
.
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
communication.
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.