skip to content

What does allow.everyone.if.no.acl.found control, and what is its default and recommended value?

level: middleimportance: must knowfreq 65%

answer

  1. fallback only when NO ACL matches
  2. false = default-deny (recommended)
  3. true = open / default-allow
  4. per-resource: one ACL locks the resource
  5. DENY still wins regardless

basics

~10 s

It controls the fallback when no ACL matches a resource: if true, access is allowed; if false, access is denied. The default is false (default-deny), which is the recommended secure posture.

solid answer

~50 s

allow.everyone.if.no.acl.found is a broker config that defines the authorizer's fallback decision when no ACL exists for the resource being accessed (and there's no explicit DENY and the principal isn't a super user). If true, the request is ALLOWED — an open/default-allow posture. If false (the default), it is DENIED — default-deny. The key subtlety: the fallback only triggers when there are NO ACLs at all for that resource. As soon as you add any ACL for a resource, that resource is governed strictly by its ACLs and the 'allow everyone' fallback no longer opens it up. Setting it true is risky because it silently grants access to any resource you forgot to protect. Production deployments keep it false so unmanaged resources are denied by default. Explicit DENY ACLs always win over both ALLOW ACLs and this fallback.

go deeper

for a junior

Know true = allow when no ACL, false = deny when no ACL, and false is the safe default.

for a middle

Explain that the fallback is per-resource and only fires when no ACL matches that resource.

for a senior

Walk the full deny→allow→fallback order and the 'one ACL locks the resource' migration gotcha.

for a principal

Design a safe authorization rollout: temporarily open fallback, add ACLs incrementally, flip to default-deny, and verify with audit/denial logs.

## The decision pipeline For each request the authorizer evaluates, in order: 1. **Super user?** → ALLOWED (bypass). 2. **Any matching DENY ACL?** → DENIED (deny wins). 3. **Any matching ALLOW ACL?** → ALLOWED. 4. **No ACL matched at all** → fall back to `allow.everyone.if.no.acl.found`. `allow.everyone.if.no.acl.found` only governs step 4 — the case where the resource has **no ACLs whatsoever** that match. ## true vs false - **`false` (default): default-deny.** A resource with no ACLs is inaccessible to everyone except super users. This is the secure, recommended posture. You must explicitly grant access. - **`true`: default-allow.** A resource with no ACLs is open to all authenticated principals. Convenient for migration/dev but dangerous in production — any topic you forget to lock down is wide open. ## The critical subtlety: per-resource, not global The fallback is evaluated **per resource**. The moment a resource has *any* matching ACL, the fallback stops applying to it — it's now governed only by its ACLs. So with `allow.everyone.if.no.acl.found=true`, adding a single ALLOW ACL to a topic effectively **locks down** that topic to only the principals named, because it no longer has 'no ACL found.' This trips people up during migrations: granting one ACL can unexpectedly cut off everyone else who relied on the open fallback. ## Interaction with DENY Explicit DENY ACLs are checked **before** ALLOW and before the fallback, so a DENY always wins regardless of this setting. You cannot override a DENY with the open fallback. ## Historical / version note The insecure-by-default era is long past for production; modern guidance (and the built-in `StandardAuthorizer` used with KRaft) defaults this to `false`. Some legacy setups flipped it to `true` to ease the rollout of authorization, intending to flip it back once ACLs were in place. ## Practical guidance - Keep it **false** in production. - If migrating, you can temporarily set it `true`, add ALLOW ACLs incrementally, then flip to `false` and verify nothing breaks (gaps now surface as denials rather than silent allows).

  • With allow.everyone.if.no.acl.found=true, what happens to a topic the moment you add one ALLOW ACL to it?
    That topic is no longer 'no ACL found,' so the open fallback stops applying to it. It becomes restricted to exactly the principals named in its ACLs — everyone else is now denied. Adding one ACL effectively locks the resource down.
  • Can the open fallback override an explicit DENY ACL?
    No. DENY ACLs are evaluated before the fallback and before ALLOW ACLs, so an explicit DENY always results in DENIED regardless of allow.everyone.if.no.acl.found.

saying these in an interview costs you the question

  • Saying the default is true — the secure default is false (default-deny).
  • Thinking the fallback is global rather than per-resource (one ACL changes a resource's behavior).
  • Claiming allow.everyone.if.no.acl.found=true can override a DENY ACL.
  • Conflating this setting with super.users — they are independent checks.

context

resolving links…