skip to content

What are Kafka's four security protocols, and what does each one provide in terms of encryption and authentication?

level: juniorimportance: must knowfreq 70%

answer

  1. 2x2: TLS? x SASL?
  2. PLAINTEXT = nothing
  3. SSL = encrypt + optional mTLS
  4. SASL_PLAINTEXT = auth, no encrypt
  5. SASL_SSL = production default

basics

~10 s

Kafka has four security protocols: PLAINTEXT (no encryption, no auth), SSL (TLS encryption, optional client cert auth), SASL_PLAINTEXT (SASL auth, no encryption), and SASL_SSL (SASL auth plus TLS encryption).

solid answer

~40 s

Kafka defines exactly four security protocols, each combining a transport layer with an authentication mechanism. PLAINTEXT: no encryption and no authentication — for trusted networks only. SSL: TLS encryption of the wire; authentication is optional and done via client X.509 certificates (mutual TLS) when ssl.client.auth=required. SASL_PLAINTEXT: SASL authentication (GSSAPI/Kerberos, PLAIN, SCRAM, OAUTHBEARER) over an unencrypted connection — credentials travel in cleartext for PLAIN, so this is risky outside a secure network. SASL_SSL: SASL authentication wrapped inside a TLS tunnel — the standard production choice because it gives both confidentiality and identity. You set the protocol per listener via listener.security.protocol.map, and clients pick one with the security.protocol property. SASL_SSL with SCRAM or OAUTHBEARER is the typical secure default.

go deeper

for a junior

Memorize the 2x2 grid and what each of the four protocols gives you (encryption vs authentication).

for a middle

Know that SSL can do mTLS and that the protocol is set per listener via listener.security.protocol.map; clients set security.protocol.

for a senior

Distinguish transport from auth, enumerate SASL mechanisms, and reason about when mTLS suffices vs when SASL is preferable.

for a principal

Tie protocol choice to threat model and network topology, and explain why encryption and authentication are orthogonal design axes.

Kafka clients and brokers speak a binary TCP protocol. Before any topic data flows, the connection is governed by a **security protocol**, which bundles two independent concerns: (1) is the connection **encrypted** on the wire, and (2) is the peer **authenticated** (do we know who it is). There are exactly four security protocols, formed by the cross-product of {plaintext transport, TLS transport} and {no SASL, SASL}: - **PLAINTEXT** — No TLS, no SASL. Bytes go over the network unencrypted and the broker accepts any connection without identifying the client. Use only on a fully trusted/private network (e.g. a single host, or a locked-down VPC with no external exposure). It is the default if you configure nothing. - **SSL** — The transport is wrapped in **TLS** (the protocol historically called SSL; Kafka keeps the legacy name). This gives **confidentiality** (eavesdroppers see ciphertext) and **integrity**. Authentication is *optional*: the broker always presents a server certificate, and if `ssl.client.auth=required` (or `requested`) the client must also present an X.509 certificate, giving **mutual TLS (mTLS)**. With mTLS the client's identity is the certificate's Distinguished Name. - **SASL_PLAINTEXT** — Authentication via **SASL** (Simple Authentication and Security Layer — a pluggable framework) but **no TLS**. SASL mechanisms include GSSAPI (Kerberos), PLAIN (username/password), SCRAM-SHA-256/512 (salted challenge-response), and OAUTHBEARER (OAuth2 tokens). Because there is no encryption, SASL/PLAIN here sends the password in cleartext — only acceptable on an already-secured network. - **SASL_SSL** — SASL authentication performed **inside a TLS tunnel**. You get both encryption and a strong client identity. This is the **standard production configuration**. **How a protocol is assigned:** Each broker listener is mapped to a protocol via `listener.security.protocol.map` (e.g. `INTERNAL:SSL,EXTERNAL:SASL_SSL`). For well-known listener names (PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL) the mapping is implicit. A client chooses its protocol with the `security.protocol` config and must match what the target listener expects. **Edge cases:** TLS alone (SSL protocol) can authenticate via mTLS, so you don't always need SASL for identity. Conversely SASL alone (SASL_PLAINTEXT) authenticates but doesn't encrypt. The two dimensions are orthogonal, which is exactly why there are four combinations and not two.

  • Can you authenticate clients without using SASL?
    Yes — with the SSL protocol and ssl.client.auth=required you get mutual TLS, where the client's X.509 certificate Distinguished Name is its identity. No SASL mechanism needed.
  • Why is SASL_PLAINTEXT with the PLAIN mechanism considered risky?
    There is no transport encryption, so the username and password are sent in cleartext and can be sniffed. PLAIN should only be used inside a TLS tunnel (SASL_SSL) or on a fully trusted network.

saying these in an interview costs you the question

  • Claiming SSL always authenticates the client (it only does so with ssl.client.auth set; otherwise only the server is authenticated)
  • Saying SASL_PLAINTEXT encrypts traffic (it does not — only SASL auth, no TLS)
  • Thinking PLAINTEXT means 'plain text topics' rather than 'no security at all'
  • Confusing the security protocol with the SASL mechanism (PLAIN/SCRAM/GSSAPI are mechanisms within SASL_*)

context

resolving links…