Mutual TLS (mTLS) authenticates both sides of a connection: each participant presents a certificate, and each verifies the other's identity through trusted certificate authorities. In Kafka, the authenticated principal is typically derived from the certificate's distinguished name, with mapping rules available for fields such as the common name. section 9.3.2 section 9.3.3
A Kafka mTLS deployment requires coordinated identity and trust configuration:
- Generate a private key and keystore for each server and client, obtain a certificate from a certificate authority, and import it into the keystore. section 9.3.2
- Populate truststores with the certificate authority and any intermediate certificates needed to validate trusted participants. section 9.3.2
- Require client authentication with ssl.client.auth and configure keystore and truststore properties on both brokers and clients. section 9.3.2
- Treat certificate lifecycle and secret storage as operational concerns; environment variables, restricted files, or secret-management vaults can replace passwords embedded in configuration. section 9.3.2
Customer 360 client traffic
A Customer 360 deployment uses mTLS between producers, consumers, Kafka Connect, Schema Registry, and brokers on exposed client traffic. Producers write to topics, consumers read from them, and platform services access their Kafka topics over the same authenticated and encrypted channel. Internal broker replication and controller traffic use SASL_PLAINTEXT on a tightly segmented network, trading lower overhead for accepted internal-network risk. section 9.3.6
Figure 9.11 Generating keys and receiving a certificate. The Party (client or server) is the entity that generates the key pair and requests a signed certificate from the certificate authority.
Use the key-generation flow to trace how either a client or server creates a key pair and receives a certificate signed by a certificate authority. section 9.3.2
