skip to content

What is SASL/GSSAPI in Kafka, and what does it let a client and broker prove to each other?

level: juniorimportance: must knowfreq 55%

answer

  1. GSSAPI = Kerberos mechanism
  2. KDC issues TGT then service ticket
  3. Broker validates with its keytab
  4. Mutual auth, no password on wire
  5. sasl.mechanism=GSSAPI

basics

~20 s

SASL/GSSAPI is Kafka's way of authenticating with Kerberos. Clients get a ticket from a Kerberos KDC and present it to the broker, so both sides prove who they are without sending passwords over the wire.

solid answer

~40 s

GSSAPI (Generic Security Services API) is the SASL mechanism Kafka uses to do Kerberos authentication. You configure it with security.protocol=SASL_PLAINTEXT or SASL_SSL and sasl.mechanism=GSSAPI. The client authenticates to a KDC (Key Distribution Center) using a keytab or a cached ticket-granting ticket, then requests a service ticket for the Kafka broker's principal (e.g. kafka/broker1.example.com@REALM). It presents that ticket; the broker validates it against its own keytab. The result is mutual authentication: the client proves its identity and the broker proves its identity, all without transmitting passwords. The negotiated Kerberos identity becomes the KafkaPrincipal used by ACL authorization. SASL only authenticates; you still add TLS (SASL_SSL) for encryption.

go deeper

for a junior

Know GSSAPI means Kerberos auth and that tickets, not passwords, are exchanged.

for a middle

Know the KDC -> TGT -> service ticket flow and the SASL_PLAINTEXT vs SASL_SSL distinction.

for a senior

Explain mutual authentication, keytab validation on the broker, and principal-to-KafkaPrincipal mapping for ACLs.

for a principal

Frame GSSAPI within an enterprise auth strategy and articulate why TLS is still required for confidentiality.

## The problem Kafka clients and brokers need to know who they are talking to before exchanging data. Sending a username and password is risky. Kerberos solves this with a trusted third party so no password ever crosses the network during authentication. ## Key terms - **SASL** (Simple Authentication and Security Layer): a pluggable framework Kafka uses to negotiate authentication. It defines *mechanisms*; GSSAPI is one of them. - **GSSAPI** (Generic Security Services API): a standard API that, in Kafka's case, wraps **Kerberos v5**. When people say 'Kafka with Kerberos,' they mean SASL/GSSAPI. - **Kerberos**: a network authentication protocol built around tickets and a trusted server. - **KDC** (Key Distribution Center): the trusted server. It has two parts — the Authentication Server (issues a Ticket-Granting Ticket, TGT) and the Ticket-Granting Server (issues service tickets). - **Principal**: an identity in Kerberos, like `[email protected]` (a user) or `kafka/[email protected]` (a service). The part after `@` is the **realm**. - **Keytab**: a file holding a principal's long-term key, so a service or app can authenticate without typing a password interactively. ## The flow 1. The client authenticates to the KDC (using a keytab or a pre-obtained TGT via `kinit`) and gets a **TGT**. 2. Using the TGT, the client asks the KDC for a **service ticket** for the Kafka broker's principal. Kafka derives that principal name from `sasl.kerberos.service.name` (usually `kafka`) plus the broker host and realm. 3. The client sends the service ticket to the broker over the SASL handshake. 4. The broker decrypts and validates the ticket using its **own keytab**. Because only the real broker holds that key, the client knows it is talking to the genuine broker — this is **mutual authentication**. 5. The authenticated Kerberos principal is mapped to a **KafkaPrincipal** (default `User:<short-or-full-name>`), which the authorizer then checks against ACLs. ## Configuration shape On the broker and client you set `security.protocol` to `SASL_PLAINTEXT` (auth only) or `SASL_SSL` (auth + TLS encryption), `sasl.mechanism=GSSAPI`, and a JAAS config (inline via `sasl.jaas.config` or a file) pointing at the keytab and principal. ## Edge cases - SASL/GSSAPI authenticates and can integrity/confidentiality-protect the SASL handshake, but for full wire encryption of data you use SASL_SSL. - DNS must resolve broker hostnames consistently; Kerberos is sensitive to host/principal name mismatches. - Clocks must be roughly in sync (typically within 5 minutes) or ticket validation fails.

  • Does SASL/GSSAPI encrypt the data Kafka sends?
    Not by itself — it authenticates. For wire encryption you combine it with TLS using security.protocol=SASL_SSL.
  • What identity does the broker use for authorization after a Kerberos login?
    The Kerberos principal is mapped to a KafkaPrincipal (default User:<name>), which the ACL authorizer checks.

saying these in an interview costs you the question

  • Saying GSSAPI encrypts the data stream on its own (it authenticates; encryption needs TLS)
  • Claiming the password is sent to the broker (Kerberos never transmits the password)
  • Confusing SASL/PLAIN or SCRAM with GSSAPI

context

resolving links…