Troubleshooting Authorizer Configuration
Frequently-asked Questions:
When should I use Deny?
Never. By default, all principals that are not explicitly granted permissions get rejected so you should not have to use Deny ever. (Note: when defined, DENY takes precedence over ALLOW.)
Then why do we have deny?
Deny was introduced into Kafka for advanced use cases where negation was required. For
example, if an admin wants to grant WRITE access to a topic from all hosts but
host1
, the admin can define two ACLs:
“grant WRITE to test-topic from hosts * for principal test-user”
“deny WRITE to test-topic from hosts host1 for principal test-user”
Deny should only be used to negate a large allow, where listing all principals or hosts is cumbersome.
Can I define ACLs with principal as user@<realm>?
You can if you are not using principal.to.local.class
, but if you have set
this configuration property you must define your ACL with users without and REALM. This is a
known issue in HDP 2.3.
I just gave a user CREATE Permissions on a cluster, but the user still can't create topics. Why?
Right now, Kafka create topic is not implemented as an API, but as a script that directly modifies ZooKeeper entries. In a secure environment only the Kafka broker user is allowed to write to ZooKeeper entries. Granting a user CREATE access does not allow that user to modify ZooKeeper entries.
However, if that user makes a producer request to the topic and has
auto.create.topics.enable
set to true
, a topic will be created at
the broker level.