Reproduced ACL (Access control list)

ZK as an important middleware in the distributed architecture, usually in the above node to store some key information, by default, all applications can read and write any node, in complex applications, it is not very safe, ZK through the ACL mechanism to solve the access problem, see the official Website document:/HTTP Zookeeper.apache.org/doc/r3.4.6/zookeeperprogrammers.html#sc_zookeeperaccesscontrol

In general, the ZK node has 5 operations permissions:

CREATE, READ, WRITE, DELETE, admin is to add, delete, change, check, management permissions, these 5 kinds of permissions shorthand for Crwda (i.e., the first character of each word abbreviated)

Note: In these 5 kinds of permissions, delete is the delete permission of the child node, and the other 4 kinds of permissions refer to the Operation permission of the node.

Identity authentication is available in 4 ways:

World: The default, which is equivalent to the worldwide access
Auth: Represents the authenticated user (the CLI can be Addauth digest user:pwd to add authorized users in the current context)
Digest: That is, user name: Password this way authentication, which is the most commonly used in business systems
IP: Using IP address authentication

The CLI command line can be tested like this:

With the Getacl command, you can find that the node you just created, by default, is the World,anyone authentication method with Cdrwa all permissions

Continue to Tinker:

Added user1:+owfosbn/am19robpzr1/mfcble read-only (r) permission control to/test first.

Description: Setacl/test Digest: User name: Password: the permission to set ACL access to the node, the password must be encrypted content, here the +owfosbn/am19robpzr1/mfcble=, the corresponding original is 12345 ( As for how this cipher is obtained, it will be said later, here, regardless of this), after the ACL is set, you can

GETACL/node path view ACL settings

Then Get/test, the authentication is invalid, indicating that access control is working, and then:

Addauth Digest user1:12345 Adds an authenticated user to the context, which corresponds to the setting for the SetACL just now

And then get/test to get the data.

Finally the Delete/test succeeded! The reason is: the root node/default is World:anyone:crdwa (that is, the world can easily toss), so that anyone can be to root node/read, write, create child nodes, manage ACLs, and delete child nodes (again, the delete permission in the ACL should be understood as the delete permission of the child node)

As mentioned earlier, Setacl/path Digest this way, you must enter the password after the encrypted value, which is not convenient on the CLI console, so the following way is more commonly used:

Note the section of the box, the first with Addauth Digest user1:12345 to add an authenticated user, and then use the Setacl/test auth:user1:12345:r set the permissions, with the same effect, but the password is entered in clear text, Manual input in console mode is more convenient.

OK, unlock the encryption rules:

1234567

static publicString generateDigest(String idPassword)        throwsNoSuchAlgorithmException {    String parts[] = idPassword.split(":", 2);    bytedigest[] = MessageDigest.getInstance("SHA1").digest(            idPassword.getBytes());    returnparts[0] + ":"+ base64Encode(digest);}

is SHA1 encryption, then Base64 encoded

Code use:

Zookeeper has a very good client-side open source Project Zkclient, the official website address is: http://github.com/zkclient, The latest film 0.7-dev has been supported ACL (old 0.1 version without this feature, so it is recommended to use the latest version), using the method:

git clone https://github.com/sgroschupf/zkclient (pull the code locally)

Modify

Build.gradle found 92 rows

+ View Code

Kill this section, or you'll get a compile error.

Then (Windows environment, convert./gradew to Gradlew)

./gradlew Test (tested)

./gradlew jars (compile build jar package)

./gradlew install (installs to native Maven repository)

To create a new MAVEN project, pom.xml reference the following settings:

View Code

Then write a code to test it:

+ View Code

Output Result:

Test-data node creation succeeded! ---------------------Org.apache.zookeeper.keeperexception$noauthexception:keepererrorcode = Noauth for/ Testorg.apache.zookeeper.keeperexception$noauthexception:keepererrorcode = Noauth for/ Testtest-data---------------------Org.apache.zookeeper.keeperexception$noauthexception:keepererrorcode = NoAuth For/testnew-data---------------------[31,s{' Digest, ' admin-user:malw21phn07yovwnkjyq2scmozw=}]----------------- ----node deleted successfully!

From the results of the zkclient, it works the same as the CLI.

Finally: the ACL between the multilevel nodes is not an inheritance relationship, but there are some connections, which are difficult to understand in the first contact ACL:

From this diagram, it can be found that the control permission range of the child node/a/b (the whole world can do anything) can go beyond the scope of the parent node (only: User-a:pwd:a has read/admin permissions)

Go on, look at the above 4 red lines labeled places, from the top down to explain each:

Red Line 1: Because/A only user-a:pwd-a has RA permissions, that is: no user has C (create) permissions, so you cannot create child nodes

Red Line 2: Because/a/b is World:anyone:cdrwa permissions, that is unrestricted, so under/a/b to create a child node B1, the Earth people have been unable to prevent, create a successful

Red Line 3:/a/b/b1 specified user-b1:pwd-b1 da permissions (i.e.: delete+admin)

( Note: revisit the SetACL two models mentioned earlier,

One is Setacl/path Digest:username:encrypedpwd:crwda in this way, the ENCRYPEDPWD user must be ciphertext,

Another way is to first Addauth Digest:usrname:password the authorization information into the context, where password is in clear text, and then Setacl/pathauth:username:password:crdwa

So if in the CLI console testing, it is strongly recommended to use the second way, otherwise, like the way in the wrong way, pwd-b1 in ZK is considered ciphertext, to decrypt it is almost impossible, so set, the equivalent of this node is wasted, because you do not know the password, to operate the node, Not provide the correct authentication information)

Red Line 4: Or just the reason, because/a/b is World:anyone:cdrwa, there is no limit, so remove the sub-node under it is not blocked.

As you can see, the contents of the parent node cannot be get, but the contents of the child nodes can be got, the permissions of the parent and child nodes are not directly related, but when you do delete, the example above is in trouble:

When you want to delete/a/b, the child node cannot be deleted because the ACL list of the parent node/A has only RA permissions and no D permission. Want to delete/A, found below also have child node B, the node is not empty can not be deleted, so this example is no solution (because according to the previous operation, the password can not be restored, you can not modify the ACL properties), and the root node/can not be deleted, the solution, only to the data directory to clear all the information, But this is tantamount to throwing all the data away, so when designing ACLs, for delete permissions, plan carefully, test the ZK cluster, and then move on to the production environment.

Finally, give some test results of the permission combination:

To modify the ACL properties of a node, you must have read, admin two permissions

To delete a child node under a node, you must have Read permission on the parent node and delete permission for the parent node

Reference article:
https://ihong5.wordpress.com/2014/07/10/apache-zookeeper-acl-access-control-list-getting-permission-sets/

https://ihong5.wordpress.com/2014/07/24/apache-zookeeper-setting-acl-in-zookeeper-client/

https://ihong5.wordpress.com/2014/06/24/znode-types-and-how-to-create-read-delete-and-write-in-zookeeper-via-zkclient/

Http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#sc_ZooKeeperAccessControl

Reproduced ACL (Access control list)