Kafka SASL/SSL authentication configuration — interactive reference

SASL mechanism comparison

PLAIN
Username + password sent in cleartext (must pair with TLS). Simple but credentials are static — rotation requires restart. Only use for dev or internal trusted networks.
SCRAM-256
Challenge-response — password never sent over wire. Credentials stored as salted hashes in ZooKeeper/KRaft. Supports online credential rotation. Recommended for most on-prem clusters.
GSSAPI
Kerberos integration. Uses Kerberos service tickets — no passwords stored in Kafka at all. Best for enterprise Hadoop environments with existing KDC. High ops complexity.
OAUTHBEARER
JWT tokens from an OAuth2 / OIDC provider (Keycloak, Okta, AWS Cognito). Token TTL typically 1h — automatic short-lived credentials. Best for cloud-native and microservice producers.

Listener architecture — separate ports per security level

listeners=PLAINTEXT://0.0.0.0:9092,SASL_SSL://0.0.0.0:9093,INTERNAL://0.0.0.0:9094 # 9092 = internal cluster comms (broker-broker), PLAINTEXT ok inside VPC # 9093 = external clients — SASL + TLS mandatory # 9094 = admin/monitoring tools — separate ACL set listener.security.protocol.map=PLAINTEXT:PLAINTEXT,SASL_SSL:SASL_SSL,INTERNAL:PLAINTEXT inter.broker.listener.name=INTERNAL

Key insight: broker-to-broker traffic can stay on PLAINTEXT inside the VPC. All external producer/consumer traffic hits the SASL_SSL listener only.