Page History

...

The current ACL used with all znodes is open for read and write access, and with this KIP we want to make it unrestricted for authenticated clients, but readable by any client. We assume that no data stored in ZooKeeper is sensitive and can be read by anyone with the ability of connecting to the ensemble, but the metadata stored in it can be used to mount specific attacks against the cluster. For example, the metadata of a broker can be manipulated or a rogue broker can be introduced and start participating in replica sets as any other broker. Note that the feature described here focuses on brokers and does not include the old consumer, since it is becoming deprecated.

...

Users need to setup a JAAS login configuration file and specify it as a system property named {{java.security.auth.login.config}}. With this property set, Kafka brokers turn security features on and use more strict ACLs rather than the open unsafe one. Specifically, it uses CREATORuses CREATOR_ALL_ACL and and READ_ACL_UNSAFE when the security feature is on, which enable the creator (or anyone with the credentials of the creator) to manipulate the znode while everyone else can read it. That's the only bit that changes to users, everything else happens under the hood.

...

There are three parts to this new feature:

• ZkUtils: Pretty much all access to ZooKeeper happens through kafka.utils.ZkUtils and the JIRA for these changes is KAFKA-2639. The main problem with the code before the changes in KAFKA-2639 is the fact that ZkUtils is a singleton object, which makes changing the ACLs from not secure to secure difficult. We need to be able to set the change ACLs dynamically at least for testing, however. In KAFKA-2639, we make ZkUtils a class and now we can determine if we want to use strict or open ACLs at instantiation.
• Configuration and upgrades: The user needs to be able to input configuration to express the interest in running a secure cluster and needs an upgrade path to bring non-secure clusters to secure. The main part of the configuration is in the JAAS login file, and we pass it to a broker via a system property. The upgrade path is discussed below, and this part of the proposal is in KAFKA-2641.
  
• Tests: This task is mainly about changing existing test cases and creating new ones to test new functionality. This part of the work is in KAFKA-2640. 

...

If a broker all of a sudden changes the ACLs of znodes to secure, then brokers without the proper configuration will not be able to access ZooKeeper data any longer. Consequently, we need a plan to migrate existing clusters . The recipe is straightforward, thoughwithout requiring such a cluster to stop to reconfigure. We currently propose the following recipe:

1. 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.
2. Execute a tool called ZkSecurityMigrator (thre is a script under ./bin and . This tool traverses the corresponding sub-trees changing the ACLs of the znodes.
3. 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.

...