...
- Perform a rolling restart setting the JAAS login file, which enables brokers to authenticate. At the end of the rolling restart, brokers are able to manipulate znodes with strict ACLs, but they will not create znodes with those ACLs.
- Perform a second rolling restart of brokers, this time setting the configuration parameter zookeeper.set.acl to true, which enables ZkUtils to use secure ACLs when creating znodes.
- Execute a tool called
ZkSecurityMigrator
(there is a script under ./bin and the code is underkafka.admin
). This tool traverses the corresponding sub-trees changing the ACLs of the znodes.
Note that ZooKeeper is not going to drop connections for unauthenticated clients. Such clients are still able to connect and read ZooKeeper content, but they cannot manipulate (create
, setData
, or delete
) znodes with the secure ACL. One ZooKeeper setting of interest on the server side is zookeeper.allowSaslFailedClients
. If this is false, then clients trying to authenticate with an incorrect configuration will have their connections dropped. Otherwise, such clients will be able to connect successfully, but will not have the right credentials set. Setting it to false prevents clients with an incorrect configuration from making progress.
Rejected Alternatives
One way to restrict access to a ZooKeeper ensemble is to use firewalls. This approach is reasonable, but difficult to implement in a fine-grained manner, which ends up leaving the metadata exposed all the same. Using traffic filtering to complement the feature described here is certainly a recommended option, so this option is not really rejected, but it is deemed insufficient.