How ZooKeeper ACL works

In this post I will describe the basic principles of how ACL works in ZooKeeper.

• ACL is not set recursively and is not inherited by the child nodes.
• If we have a read-only ACL for /path1/path2 or /path1/path2/path3, then deleting /path1 will fail, regardless of AСL of /path1.
• Several ACL records can be set on one node.
• You cannot change the ACL, each call to the setAcl command erases everything for current node that is already set and install new records.
• One ACL record is a collection of 3 elements: authentication scheme, client id and permissions string.
• The main authentication schemes in ZooKeeper are ip, world, x509, sasl.
• The client ID depends on the selected scheme. In the case of world these are constants like “anyone” etc., in the case of x509 it is the DN of the client certificate, in the case of sasl + digest it is the username, in the case of sasl + kerberos it is the principal name.
• Permissions. cdrwa – all permissions. The main ones are: c – create nodes, r – read, w – write. Any combination of resolutions can be used.
• Through ZooKeeper-CLI, the ACL can be get with this command:

getAcl /your/path

• And set with the command:

setAcl /your/node scheme:auth_id:permissions

• The Java ACL is get with zooKeeper.getACL() and set with the zooKeeper.setACL() commands. An example is here: https://mchesnavsky.tech/zookeeper-x509-certificates-acl
• Zooker has problems setting ACL x509. They are written here: https://mchesnavsky.tech/zookeeper-x509-certificates-acl

If you still have any questions, feel free to ask me in the comments under this article or write me at promark33@gmail.com.

​