Zookeeper using ACLs for access control

Zookeeper uses ACLs to control access to nodes, and ACLs are implemented similar to access permissions for UNIX files: use BITS to control the scope and access permissions for node access. But unlike UNIX file systems, for standard scopes, including user (owner of file), group and World (other), zookeeper nodes are not limited. Zookeeper does not have the concept of a znode owner, instead, ACLs specify a set of IDs and licenses that correspond to those IDs. The
Note that an ACL is only related to a specific znode and is not passed to the child node, for example, if/app is only ip:172.16.16.1 readable,/app/status is world readable, then anyone can read/app/status ; The ACL is not recursive. The
Zookeeper supports pluggable authentication schemes. ID uses the form of scheme:expression, scheme is the ID corresponding to the authentication scheme, the effective collection of expression is defined by scheme, for example, ip:172.16.16.1 is a id,scheme is IP, Expression is the host address 172.16.16.1;digest:bob:password is also a id,scheme is Digest,expression is the user named Bob User.
When a client connects to zookeeper for authentication, zookeeper gets all the IDs associated with that client. When a client attempts to connect to a node, the zookeeper uses the ACL of the node to check for these IDs. The form of an ACL is (scheme:expression, perms), and the format of expression is determined by scheme, for example, (Ip:19.22.0.0/16,read) that has read permissions on all clients that start with IP 19.22. ACL Permissions

The zookeeper supports the following permissions: Create: Has the privilege of creating a child node; READ: has permission to get node data and child lists; WRITE: has permission to set node data; Delete: has permission to delete node data; ADMIN: Has permission to set permissions.
The Create and delete licenses are separated from the write license for finer-grained access control. Consider the following scenario: you want A to set a value for the Zookeeper node, but not create and delete the child. Scenario with create permission but no delete permission: The client creates a zookeeper node on the parent node by sending a create request. You want all clients to be able to add to this node, but only the creator can delete (similar to the file's append permissions).
The admin permission exists because the zookeeper does not have the concept of a file owner. In a sense, the admin permission specifies the so-called owner. Zookeeper Although lookup permissions are not supported (the Execute permission on the directory is not listed but can be found), each client implicitly has lookup permissions. This way you can view the node status, but that's all. (There is a problem, if you call Zoo_exists () on a nonexistent node, you will not have permission to view it). built-in ACL scheme

Zookeeper has the following built-in scenarios:
-World: Independent Id,anyone, representing all people;
-AUTH: Do not use any ID to indicate any authenticated user;
-Digest: Uses a string formatted as Username:password to generate an MD5 hash table as an ACL ID, sending Username:password in an empty document to complete the authentication. Now the ACL expression format is USERNAME:BASE64, encoded with SHA1 password;
-IP: Use the client IP as the ACL ID. The format of the ACL expression is the most efficient bit in addr/bits,addr that matches the most efficient bit of the client host IP;
-X509: Using the client X500 principal as the ACL id,acl expression is the X500 principal name of the client. When a secure port is used, the client is automatically authenticated and their authentication information is set.