skip to content

What is SASL in Kafka, and what is the difference between the PLAIN and SCRAM SASL mechanisms?

level: juniorimportance: must knowfreq 70%

answer

  1. SASL = pluggable auth framework
  2. PLAIN = cleartext password, needs TLS
  3. SCRAM = salted challenge-response, no password on wire
  4. mechanism vs security protocol (PLAIN != PLAINTEXT)
  5. SCRAM creds live in ZK/KRaft, managed by kafka-configs

basics

~10 s

SASL is Kafka's pluggable authentication framework. PLAIN sends a username and password (must run over TLS). SCRAM uses a salted challenge-response so the raw password never travels the wire.

solid answer

~40 s

SASL (Simple Authentication and Security Layer) is the framework Kafka uses to authenticate clients and brokers. You pick a mechanism via the sasl.mechanism property. PLAIN transmits the username and password essentially in cleartext inside the SASL exchange, so it MUST be wrapped in TLS (SASL_SSL) or credentials leak. SCRAM (Salted Challenge Response Authentication Mechanism), available as SCRAM-SHA-256 and SCRAM-SHA-512, never sends the password itself: the broker stores a salted hash, and client and server prove knowledge through a challenge-response handshake. SCRAM credentials are managed by Kafka itself (stored in ZooKeeper or KRaft metadata) and created via kafka-configs --alter, whereas PLAIN credentials are typically static entries in the broker JAAS config. Both protect listeners selected by the listener's security protocol (SASL_PLAINTEXT or SASL_SSL).

go deeper

for a junior

Know SASL is the auth framework, PLAIN = password in cleartext (needs TLS), SCRAM = hashed challenge-response.

for a middle

Distinguish mechanism from security protocol; know SCRAM creds are managed via kafka-configs and stored hashed.

for a senior

Explain the salted challenge-response handshake, SHA-256/512 variants, and why SCRAM is safer on the wire than PLAIN.

for a principal

Reason about credential lifecycle, rotation, storage location (ZK vs KRaft), and the layering of mechanism over transport when designing a cluster auth strategy.

## What SASL is **SASL** stands for *Simple Authentication and Security Layer*. It is a generic, pluggable framework (defined outside Kafka, in RFC 4422) for adding authentication to connection-oriented protocols. Kafka adopts it so the same wire protocol can support many different authentication 'mechanisms' without changing the protocol itself. You choose the mechanism on the client with the property `sasl.mechanism` and enable it on the broker by listing it in `sasl.enabled.mechanisms`. ## The transport vs. the mechanism Two independent choices exist: - **Security protocol** of a listener: `PLAINTEXT`, `SSL`, `SASL_PLAINTEXT`, or `SASL_SSL`. This decides whether the *connection* is encrypted (TLS) and whether SASL authentication runs. - **SASL mechanism**: `PLAIN`, `SCRAM-SHA-256`, `SCRAM-SHA-512`, `GSSAPI` (Kerberos), `OAUTHBEARER`. This decides *how* the identity is proven. Note the unfortunate name collision: the *protocol* word `PLAINTEXT` (no TLS) is different from the *mechanism* `PLAIN`. ## PLAIN mechanism The `PLAIN` mechanism sends the username and password to the broker in the SASL handshake essentially as cleartext. The broker validates them against credentials configured in its JAAS login config. Because the password is exposed on the wire, PLAIN must be combined with TLS — use the `SASL_SSL` security protocol, never `SASL_PLAINTEXT`, in production. PLAIN credentials are usually *static*: they are listed inside the broker's `sasl.jaas.config` (or a separate JAAS file) and changing them requires editing config and (often) restarting brokers. ## SCRAM mechanism `SCRAM` = *Salted Challenge Response Authentication Mechanism* (RFC 5802). Kafka offers `SCRAM-SHA-256` and `SCRAM-SHA-512` (the number is the hash strength). Key properties: - The broker stores a **salted, iterated hash** of the password, not the password itself. - Authentication is a **challenge-response**: the server sends a random nonce/salt, the client computes a proof using the password and the salt, and the server verifies the proof. The raw password is never transmitted. - Credentials are **managed by Kafka** and stored in ZooKeeper (pre-KRaft) or in the **KRaft metadata log**, created/updated/deleted dynamically with `kafka-configs --alter --add-config 'SCRAM-SHA-256=[password=...]' --entity-type users --entity-name alice` with **no broker restart**. Because SCRAM does not put the password on the wire, it is safer than PLAIN even if TLS is misconfigured — but you should still run it over `SASL_SSL` so the rest of the traffic (data, ACLs) is encrypted. ## Summary contrast | | PLAIN | SCRAM | |---|---|---| | Password on wire | cleartext (needs TLS) | never (challenge-response) | | Credential storage | static JAAS config | ZK / KRaft metadata, hashed+salted | | Add/rotate user | edit config + restart | `kafka-configs --alter`, live | | Variants | one | SHA-256, SHA-512 |

  • Why must PLAIN be used with SASL_SSL and not SASL_PLAINTEXT?
    PLAIN sends the password as cleartext inside the SASL exchange. Without TLS (SASL_PLAINTEXT), anyone sniffing the network captures the credentials. SASL_SSL wraps the handshake in TLS so the password is encrypted in transit.
  • Where are SCRAM credentials stored and how do you create one?
    In ZooKeeper for legacy clusters or in the KRaft metadata log for KRaft clusters, as salted hashes. You create one with kafka-configs.sh --alter --add-config 'SCRAM-SHA-256=[iterations=8192,password=secret]' --entity-type users --entity-name alice, with no broker restart.

saying these in an interview costs you the question

  • Confusing the PLAIN mechanism with the PLAINTEXT security protocol
  • Claiming SCRAM encrypts traffic — it authenticates only; you still need TLS for confidentiality
  • Saying PLAIN is fine without TLS because 'it's SASL'
  • Thinking SCRAM stores the cleartext password on the broker

context

resolving links…