Learn Labs
11. Securing Kafka

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 authenticationSSL client authSASL auth
PLAINTEXT transportPLAINTEXT—SASL_PLAINTEXT
SSL transportSSL — encrypted, server authSSLSASL_SSL
ProtocolDescriptionSuitability
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=BROKER

Selecting 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.


On this page