TLS protects Kafka traffic with encryption and authenticated connections. It is typically applied to both client–broker and broker–broker communication, making transport encryption a baseline requirement rather than an optional enhancement. section 13.2.1 section 13.4
A broker receives a public–private key pair signed by a central Certificate Authority (CA). Its keystore stores the private key, while a truststore containing the CA public key lets clients and brokers verify trusted peers. TLS improves protection but adds configuration work and can reduce performance, so heavily loaded clusters should be tested before migration. section 13.2.1
listeners=PLAINTEXT://$IP:9092,SSL://$IP:9093 #1
listener.security.protocol.map=\
PLAINTEXT:PLAINTEXT,SSL:SSL #2
ssl.keystore.location=/home/user/certs/broker.ks.p12 #3
ssl.keystore.type=PKCS12 #3
ssl.keystore.password=keystore-pw #3
ssl.key.password=keystore-pw #3
ssl.truststore.location=\
/home/user/certs/ca.truststore.p12 #4
ssl.truststore.password=truststore-pw #4
ssl.truststore.type=PKCS12 #4
Use the configuration listing as a starting point for a transition: expose both PLAINTEXT and SSL listeners, map their protocols, and configure PKCS12 keystores and truststores. section 13.2.1
Migrating an existing cluster
A Kafka environment that currently communicates without security can add encrypted listeners alongside unencrypted ones, reconfigure clients and brokers, and restart brokers sequentially. This supports migration without affecting availability, while performance testing reveals whether TLS overhead is acceptable. section 13.2.1 section 13.4
