A client connecting to a Kafka broker must establish who it is before its actions can be checked. Kafka authenticates the client during connection setup; that identity remains in place for the session. Authorization is a separate step that determines what the client may do. section 13.2 section 13.2.2
After establishing an encrypted connection, choose how clients will prove their identity. Mutual TLS extends the TLS setup so clients present certificates to brokers; each client needs a key pair signed by the certificate authority. Alternatively, Kafka supports authentication through Simple Authentication and Security Layer (SASL). section 13.2.2
Making a certificate identity usable
With mutual TLS, Kafka uses the certificate’s full Distinguished Name as the principal by default—for example, CN=alice,OU=myOrgUnit,O=SampleCorp,L=SampleCity,ST=SampleState,C=SampleCountry. If the Common Name is sufficient for permissions, principal-mapping rules can extract alice instead. section 13.2.2
listener.name.ssl.ssl.principal.mapping.rules= \
RULE:^CN=([^,]*).*$/$1/L ,\
DEFAULT
This listener configuration extracts the Common Name from a certificate Distinguished Name for use as a principal. section 13.2.2
Plan for the session boundary: if an attacker takes over an authenticated client, deleting its Kafka user does not end the established identity; revoke that user’s permissions too. Unauthenticated clients have the principal User:ANONYMOUS, to which permissions can also be assigned or denied. For ZooKeeper-based clusters, secure broker-to-ZooKeeper authentication as well; mutual TLS is recommended, and ZooKeeper also supports SASL. section 13.2.2 section 13.2.6
