Configuring Kafka for Kerberos Over Ambari
Also available as:
PDF

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.