🚨 Kafka Error Guide: 'AuthorizationException' Not Authorized to Access

Exact Error Message

An authorization failure appears after a successful login, when the authenticated principal attempts an operation it has no permission for:

[2026-06-29 09:14:55,217] ERROR [Producer clientId=orders-producer] Aborting producer
batches due to fatal error (org.apache.kafka.clients.producer.internals.Sender)

org.apache.kafka.common.errors.AuthorizationException: Not authorized to access
this resource
    at org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:271)

The broker authorizer logs the corresponding denial:

[2026-06-29 09:14:55,210] INFO Principal = User:orders-producer is Denied operation =
Write from host = 10.0.6.18 on resource = Topic:LITERAL:orders for request = Produce
(kafka.authorizer.logger)

Related phrasings include “not authorized to access”, “Principal not authorized”, and the generic AuthorizationException that wraps the more specific topic, group, and cluster subclasses.

What the Error Means

AuthorizationException means authentication already succeeded — the broker knows who you are — but the configured authorizer (typically StandardAuthorizer in KRaft mode or AclAuthorizer in ZooKeeper mode) found no matching ACL that permits the requested operation on the requested resource. Kafka authorization is default-deny: unless an explicit ALLOW ACL matches the principal, host, operation, and resource, the request is rejected.

This is fundamentally different from SaslAuthenticationException, which is an identity failure during the handshake. Here the identity is established and trusted; the problem is the permission grant. The denial line in kafka.authorizer.logger is the authoritative record of exactly which principal, host, operation, and resource were involved.

Common Causes

• No ACL exists for the principal on the target resource. With default-deny, missing equals denied.
• allow.everyone.if.no.acl.found=false (the secure default) means resources without any ACL deny everyone except super users.
• Principal name mismatch: the authenticated principal (e.g. User:CN=orders,OU=apps) does not match the principal the ACL was written for (User:orders). SSL principal mapping rules and SASL short names are frequent culprits.
• Wrong resource pattern type: an ACL written as PREFIXED does not match a LITERAL lookup, or the topic name differs by case.
• Operation not granted: a producer needs Write and Describe; granting only Read still denies it.
• Authorizer not configured at all, or the principal not listed in super.users when it was expected to be.

How to Reproduce the Error

Authenticate as a principal that has no ACL for a topic, then attempt to produce:

cat > /tmp/app-client.properties <<'EOF'
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="orders-producer" password="REDACTED";
ssl.truststore.location=/etc/kafka/ssl/truststore.jks
ssl.truststore.password=changeit
EOF

kafka-console-producer.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --topic orders --producer.config /tmp/app-client.properties <<< "test"

If orders-producer has no Write ACL on orders, the producer aborts with AuthorizationException: Not authorized to access this resource.

Diagnostic Commands

All commands below are read-only.

# List every ACL the cluster currently holds
kafka-acls.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --command-config /etc/kafka/admin.properties --list

# Narrow to the specific principal in the denial line
kafka-acls.sh --bootstrap-server broker-01.kafka.internal:9094 \
  --command-config /etc/kafka/admin.properties \
  --list --principal User:orders-producer

# Confirm the authorizer and the default-deny setting
grep -E 'authorizer.class.name|allow.everyone.if.no.acl.found|super.users' \
  /etc/kafka/server.properties

# See the exact Denied line: principal, host, operation, resource
sudo journalctl -u kafka --since "15 min ago" | grep -i "is Denied operation"

# If SSL is used, check how the cert DN maps to a principal
grep -E 'ssl.principal.mapping.rules' /etc/kafka/server.properties

The denial log line plus the ACL list together reveal whether the ACL is missing, written for the wrong principal, or has the wrong resource pattern.

Step-by-Step Resolution

1. Capture the denial line from kafka.authorizer.logger. It names the exact principal, host, operation, and resource — copy these verbatim.
2. List existing ACLs for that principal with kafka-acls.sh --list --principal .... Compare against what the denial requested.
3. Check the principal spelling. If the cert DN is CN=orders,OU=apps but the ACL targets User:orders, fix the ssl.principal.mapping.rules or rewrite the ACL to match the real principal.
4. Verify the resource pattern type. A LITERAL topic ACL will not satisfy a request expecting a PREFIXED grant; align the pattern and case.
5. Grant the missing operation. Producers need Write + Describe; consumers need Read + Describe plus a group Read. (ACL creation is a separate mutating step done by an operator.)
6. Reconsider allow.everyone.if.no.acl.found. Keep it false for security, but be aware it is why unmanaged topics deny by default.
7. Retry the operation and confirm the denial disappears from the authorizer log.

Prevention and Best Practices

• Manage ACLs as code so every topic and group has an explicit, reviewed grant rather than relying on allow.everyone.
• Keep allow.everyone.if.no.acl.found=false and use super.users only for break-glass admin identities.
• Standardize principal naming — pick predictable ssl.principal.mapping.rules so cert DNs map to stable, ACL-friendly names.
• Grant least privilege: Write+Describe for producers, Read+Describe+group Read for consumers; avoid blanket All.
• Enable the authorizer log and alert on is Denied operation so missing ACLs surface immediately. The free incident assistant can map a denial line to the missing grant.

Related Errors

• TopicAuthorizationException — the topic-specific subclass; same root cause, narrower scope.
• GroupAuthorizationException — consumer group access denied.
• ClusterAuthorizationException — a cluster-level operation (e.g. idempotent write, create topics) denied.
• SaslAuthenticationException — login itself failed; authorization never ran.

Frequently Asked Questions

What is the difference between authentication and authorization errors? Authentication (SaslAuthenticationException) decides who you are during the handshake. Authorization (AuthorizationException) decides what you may do afterward. A login can succeed and still be denied here.

Why does my topic deny everyone even though I set up SASL? With allow.everyone.if.no.acl.found=false and no ACL on the topic, default-deny applies. You must add an explicit ALLOW ACL.

The ACL exists but I am still denied. Why? The principal in the ACL probably does not match the authenticated principal exactly (DN mapping, case, or User: prefix), or the resource pattern type (LITERAL vs PREFIXED) does not match.

Where is the precise reason logged? In kafka.authorizer.logger, visible via journalctl. The is Denied operation line lists principal, host, operation, and resource.

Are super users subject to ACLs? No. Principals in super.users bypass ACL checks entirely, which is why they should be limited to admin identities.