11.2 Security protocols — the 2×2 matrix
That last point matters operationally: a client bootstrapping against the EXTERNAL port will only ever be told about EXTERNAL endpoints.
"Kafka brokers are configured with listeners on one or more endpoints... Each listener can be configured with its own security settings. Security requirements on a private internal listener that is physically protected... may be different from the requirements of an external listener accessible over the public internet."
Two standard technologies:
- TLS (Transport Layer Security), “commonly referred to by the name of its predecessor, Secure Sockets Layer (SSL)” — supports Encryption as well as Client and server authentication.
- SASL (Simple Authentication and Security Layer) — “a Framework for providing authentication using Different mechanisms in connection-oriented protocols.”
Each Kafka security protocol = a transport layer + an optional authentication layer:
| No authentication | SSL client auth | SASL auth | |
|---|---|---|---|
| PLAINTEXT transport | PLAINTEXT | — | SASL_PLAINTEXT |
| SSL transport | SSL — encrypted, server auth | SSL | SASL_SSL |
| Protocol | Description | Suitability |
|---|---|---|
| PLAINTEXT | "PLAINTEXT transport with no authentication" | "only for use within private networks for processing data that is not sensitive" |
| SSL | "SSL transport with optional SSL client authentication" | ✅ "suitable for use in insecure networks" |
| SASL_PLAINTEXT | "PLAINTEXT transport with SASL client authentication. Some SASL mechanisms also support server authentication." | ⚠️ "Does NOT support encryption and hence is suitable only within private networks" |
| SASL_SSL | "SSL transport with SASL authentication" | ✅ "suitable for use in insecure networks" |
TLS/SSL background
"TLS relies on a Public Key Infrastructure (PKI) to create, manage, and distribute digital certificates that can be used for asymmetric encryption, AVOIDING THE NEED FOR DISTRIBUTING SHARED SECRETS between servers and clients. Session keys generated during the TLS handshake enable SYMMETRIC encryption with higher performance for subsequent data transfer."
Multi-listener configuration — the canonical production example
listeners=EXTERNAL://:9092,INTERNAL://10.0.0.2:9093,BROKER://10.0.0.2:9094
advertised.listeners=EXTERNAL://broker1.example.com:9092,\
INTERNAL://broker1.local:9093,\
BROKER://broker1.local:9094
listener.security.protocol.map=EXTERNAL:SASL_SSL,INTERNAL:SSL,BROKER:SSL
inter.broker.listener.name=BROKERSelecting the inter-broker listener: inter.broker.listener.name or security.inter.broker.protocol.
⚠️ "BOTH server-side AND client-side configuration options must be provided in the BROKER configuration for the security protocol used for inter-broker communication. This is because brokers need to establish CLIENT connections for that listener."
Client side:
security.protocol=SASL_SSL
bootstrap.servers=broker1.example.com:9092,broker2.example.com:9092💡 "Metadata returned to clients contains ONLY the endpoints corresponding to THE SAME LISTENER as the bootstrap servers."
That last point matters operationally: a client bootstrapping against the EXTERNAL port will only ever be told about EXTERNAL endpoints. Listener isolation is enforced by the metadata response, not just by firewalls.
11.1 The five security procedures, and the reference data flow
Note that availability is a security concern here, not just an ops concern — and that it explicitly includes ZooKeeper.
11.3 Authentication
KafkaPrincipal is established during authentication based on the protocol (e.g. User:Alice) and can be customized via principal.builder.class.