ZooKeeper ACLs Best Practices: Kafka

You must follow the best practices for tightening the ZooKeeper ACLs or permissions for Kafka when provisioning a secure cluster.

ZooKeeper Usage:
- /controller - Kafka Znode for controller leader election
- /brokers - Kafka Znode for broker metadata
- /kafka-acl - Kafka Znode for SimpleAclAuthorizer ACL storage
- /admin - Kafka admin tool metadata
- /isr_change_notification - Track changes to In Sync Replication
- /controller_epoch - Track movement of controller
- /consumers - Kafka Consumer list
- /config - Entity configuration
Default ACLs:
- N/A -->
Security Best Practice ACLs/Permissions and Required Steps:
- /controller - world:anyone:r
- /controller - sasl:kafka:cdrwa
- /brokers - world:anyone:cdrwa
- /kafka-acl - sasl:kafka:cdrwa
- /admin - world:anyone:cdrwa
- /isr_change_notification - world:anyone:r
- /isr_change_notification - sasl:kafka:cdrwa
- /controller_epoch - world:anyone:cdrwa
- /consumers - world:anyone:cdrwa
- /config - world:anyone:cdrwa
When security is enabled zookeeper.set.acl=true should be in kafkaConfig. Which is not happening now. Users can add this using Advanced Property zookeeper.set.acl and add a new zkroot to zookeepr.connect = "host.name:2181:/kafka" to create new nodes as it won't update the ACLs on existing node. Alternatively, they can use kafka.service.keytab to log into zookeeper and set ACLs recursively.