skip to content

What is the super.users setting in Kafka, and what happens when a principal is listed in it?

level: juniorimportance: must knowfreq 70%

answer

  1. super.users = full bypass of ACLs
  2. semicolon-separated, User:name
  3. must match KafkaPrincipal exactly
  4. for inter-broker + break-glass admin
  5. authenticate yes, authorize bypassed

basics

~10 s

super.users is a broker config listing principals that are granted full access and bypass all ACL checks. Any principal in the list is always authorized for every operation, no ACLs needed.

solid answer

~40 s

super.users is a broker-side configuration (set in server.properties) listing principals who bypass the authorizer entirely. When the authorizer evaluates a request, it first checks whether the requesting KafkaPrincipal is a super user; if so it short-circuits to ALLOWED without consulting any ACLs. The format is a semicolon-separated list of fully-qualified principals, e.g. super.users=User:admin;User:kafka. The principal type (usually User) and name must match exactly what the KafkaPrincipalBuilder produces for that connection (the SSL DN or SASL identity). Super users are typically reserved for inter-broker communication and admin/break-glass accounts. Because they bypass ACLs completely, the list should be kept minimal — there is no per-resource scoping for a super user.

go deeper

for a junior

Know that super.users = principals that bypass all ACL checks and have full access.

for a middle

Know the semicolon-separated User:name format and that the name must match the KafkaPrincipal exactly.

for a senior

Explain the short-circuit-before-ACL evaluation, mTLS DN vs SASL name matching, and why the list must stay minimal.

for a principal

Reason about super.users in inter-broker security, break-glass bootstrap, and the audit/least-privilege tradeoffs of unscoped bypass.

## What this is Kafka secures who-can-do-what through an **authorizer** — a pluggable component the broker invokes on every request to decide ALLOWED or DENIED. Authorization is normally driven by **ACLs** (Access Control Lists): explicit rules saying principal X may perform operation Y on resource Z. **`super.users`** is a broker configuration that defines a set of principals exempt from this ACL machinery. A *principal* is the authenticated identity of a client — represented as a `KafkaPrincipal`, which has a **type** (almost always `User`) and a **name** (the authenticated identity string, such as an mTLS certificate's Distinguished Name or a SASL username). ## How it behaves When a request arrives, the authorizer's first check is essentially: *is this principal a super user?* If yes, it returns ALLOWED immediately and **never looks at ACLs**. This is a hard bypass — there is no way to restrict a super user to certain topics or operations. They can produce, consume, create/delete topics, alter configs, manage ACLs — everything. ## Configuration format It is a **semicolon-separated** list (not comma) of fully-qualified principals: ``` super.users=User:admin;User:broker-kafka ``` The string after `User:` must match **exactly** (case-sensitive) what the broker's `KafkaPrincipalBuilder` produces for that connection. For mTLS that is the certificate DN (e.g. `User:CN=admin,OU=ops,O=acme`); for SASL/SCRAM or SASL/PLAIN it is the username. ## Why it exists - **Inter-broker traffic** needs a principal that always works, regardless of ACL state. - **Bootstrap / break-glass**: you need *some* account to create the very first ACLs before any ACLs exist. - **Operational admin accounts** for tooling. ## Edge cases & cautions - A typo (wrong type, wrong DN ordering, extra whitespace) means the principal silently is **not** a super user and falls through to ACL evaluation. - Super users bypass authorization but still must **authenticate** — they are not anonymous backdoors. - Keep the list short; each entry is unrestricted, unauditable-by-ACL power.

  • Does a super user still need to authenticate?
    Yes. super.users only bypasses authorization (ACL checks), not authentication. The connection must still present a valid mTLS cert or SASL credential; the resulting principal is then matched against the super.users list.
  • What's a common reason a configured super user still gets denied?
    The principal string doesn't match exactly what the KafkaPrincipalBuilder emits — e.g. the mTLS DN component order or spacing differs, wrong case, or comma vs semicolon separator. The list is matched literally.

saying these in an interview costs you the question

  • Saying super.users grants extra ACLs or is just a default-allow ACL — it is a full bypass, not an ACL.
  • Claiming the list is comma-separated (it is semicolon-separated).
  • Thinking a super user can be scoped to specific topics/operations — it cannot.
  • Believing super users skip authentication too.

context

resolving links…