What is the super.users setting in Kafka, and what happens when a principal is listed in it?
answer
- super.users = full bypass of ACLs
- semicolon-separated, User:name
- must match KafkaPrincipal exactly
- for inter-broker + break-glass admin
- authenticate yes, authorize bypassed
basics
~10 ssuper.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 ssuper.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
Know that super.users = principals that bypass all ACL checks and have full access.
Know the semicolon-separated User:name format and that the name must match the KafkaPrincipal exactly.
Explain the short-circuit-before-ACL evaluation, mTLS DN vs SASL name matching, and why the list must stay minimal.
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.