Details
Description
The ZkSecurityMigrator tool fails to handle installations where kafka is configured with a zookeeper chroot (as opposed to using /, the default):
- ACLs on existing nodes are not modified (they are left world-modifiable)
- New nodes created by the tool are created directly under the zookeeper root instead of under the chroot
The tool does not emit any message, thus the unsuspecting user can only assume everything went well, when in fact it did not and znodes are still not secure:
kafka_2.12-2.3.0 $ bin/zookeeper-security-migration.sh --zookeeper.acl=secure --zookeeper.connect=localhost:2181
kafka_2.12-2.3.0 $
For example, with kafka configured to use /kafka as chroot (zookeeper.connect=localhost:2181/kafka), the following is observed:
- Before running the tool
- Zookeeper top-level nodes (all kafka nodes are under /kafka):
[zk: localhost:2181(CONNECTED) 1] ls /
[kafka, zookeeper] - Example node ACL:
[zk: localhost:2181(CONNECTED) 2] getAcl /kafka/brokers
'world,'anyone
: cdrwa
- Zookeeper top-level nodes (all kafka nodes are under /kafka):
- After running the tool:
- Zookeeper top-level nodes (kafka nodes created by the tool appeared here):
[zk: localhost:2181(CONNECTED) 3] ls /
[admin, brokers, cluster, config, controller, controller_epoch, delegation_token, isr_change_notification, kafka, kafka-acl, kafka-acl-changes, kafka-acl-extended, kafka-acl-extended-changes, latest_producer_id_block, log_dir_event_notification, zookeeper] - Example node ACL:
[zk: localhost:2181(CONNECTED) 4] getAcl /kafka/brokers
'world,'anyone
: cdrwa - New node ACL:
[zk: localhost:2181(CONNECTED) 5] getAcl /brokers
'sasl,'kafka
: cdrwa
'world,'anyone
: r
- Zookeeper top-level nodes (kafka nodes created by the tool appeared here):
Attachments
Issue Links
- links to