Mutual TLS authenticates both sides of a Kafka connection with certificates. TLS normally authenticates brokers to clients; mutual TLS extends that connection so clients also prove their identity to brokers. section 13.2.2
Each client needs a TLS key pair signed by the certificate authority (CA). During connection setup, the broker authenticates the client, and that authentication remains effective for the entire session. Revoking permissions alone is insufficient if a compromised client still controls an active identity. section 13.2.2
Turning a certificate into a Kafka principal
Kafka can use the certificate’s complete Distinguished Name (DN) as the authorization principal, such as CN=alice,OU=myOrgUnit,O=SampleCorp,L=SampleCity,ST=SampleState,C=SampleCountry. A principal-mapping rule can instead extract CN=alice, making authorization rules easier to address. section 13.2.2
CN=alice,OU=myOrgUnit,O=SampleCorp,L=SampleCity,ST=SampleState,C=SampleCountry
Inspect a complete certificate Distinguished Name and identify the Common Name used for a simpler principal. section 13.2.2
listener.name.ssl.ssl.principal.mapping.rules= \
RULE:^CN=([^,]*).*$/$1/L ,\
DEFAULT
Inspect the Kafka listener setting that extracts the certificate Common Name with a regular expression and falls back to the default rule. section 13.2.2
Use mutual TLS where certificate-based identity fits the security boundary:
- Authenticate Kafka clients to brokers instead of relying only on TLS transport encryption. section 13.2.2
- Authenticate brokers to ZooKeeper with mutual TLS when securing ZooKeeper-based Kafka clusters. section 13.2.6
- Keep ZooKeeper inaccessible to clients and monitor latency because encryption must not undermine cluster availability. section 13.2.6
