Zookeeper's ACL (Access Control List) is divided into three dimensions: scheme, id, permission
- scheme: represents the authorization strategy, which mechanism is used
- id: represents the user
- permission: stands for permission, such as read-only, read-write, management, etc.
Zookeeper provides the following mechanisms (scheme):
- world: There is only one id below it, called anyone, world: anyone represents anyone, and the node in zookeeper that has permissions to everyone belongs to world: anyone
- auth: it does not require an id, as long as the user through authentication has permissions (zookeeper supports authentication through kerberos, and also supports authentication in the form of username / password)
- digest: its corresponding id is username: BASE64 (SHA1 (password)), it needs to pass authentication in the form of username:
- ip: its corresponding id is the client's IP address, you can set an ip segment when setting, such as ip: 192.168.1.0/16, which means match the IP segment of the first 16 bits
Let's first look at the common commands of ACL, as follows:
- getAcl: Get the ACL information of the specified node
- setAcl: Set the ACL information of the specified node
- addauth: registration session authorization information
First of all, let ’s first get the ACL information of the specified node and view it as follows:
we can clearly see that the value of its scheme is world, which means anyone, and then the id value of world is anyone, and finally its permissions, value For cdrwa, its meaning is divided into: create, delete, read, write, admin.
- create: whether to have permission to create nodes
- delete: Is there permission to delete the node
- read: whether to have permission to read data
- write: whether there is permission to modify the node, the following set method
- admin: Is there the right to set permissions for child nodes
After clarifying the meaning of the above node permissions, we can use setAclcommands to change the permissions of the node. First, we remove the delete permission of the node1 node. This is the node1 node has only cwra permissions
Then we create a child node under node1 node, and then delete the test, as follows:
If we need to delete, we need to use the setAclcommand to give the node1 node delete permission
We introduced the above-mentioned getAcland setAclusage, if we may need to set up the account password, not everyone can operate it? Here we need to use the addauthcommand, which can be used to register session authorization information. Next, let's take a look at how to use it. First, let's create a node node2
We then use addauthto sign up for a session authorization, and then give you just created node node2 crwa given permission to user1 session
This is because we have not quit, so that the operation can be carried out crwa node, where we first execute quitcommand to exit, and then to connect, and then re-create the node under test node node2
It is found that it cannot be created here, so when we need to operate the node2 node, we need to first obtain the session permissions set before, as follows:
The above actually introduces the second mechanism of our scheme-auth, so what is the difference between it and the third mechanism-digest? In fact, the main difference is that one is plain text and the other is cipher text.
We can see that when we use auth to set permissions for nodes, we use plain text, as follows
Then when we use the digest to grant permissions to the node, we need to use the ciphertext here. Here we use the digest mechanism to add the delete permission of the node2 node back, as follows
So now there is a problem, we know that the account password is user1: 123456, so how do we get its ciphertext and then setAclorder it? Here we can get the ciphertext by the following command:
java -Djava.ext.dirs=/home/zookeeper/lib -cp /home/zookeeper/zookeeper-3.4.12.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider user1:123456
In addition, we can also generate ciphertext in the code of Zookeeper, see the DigestAuthenticationProvider class below. In the project, we first need to introduce Zookeeper's dependencies
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.4.12</version>
</dependency>
There is a Main method under this class, we only need to pass in the parameters, we can get the corresponding ciphertext
In fact, this encryption method we also mentioned above, is SHA1 plus BASE64 encoding
Finally, when you learn ACL permission control, if you have registered session authorization information, set the node's permissions to read-only operations, it has neither delete permissions (d) nor administrator permissions (a) , So we can't reauthorize it, so what should we do then?
In fact, we can add a super administrator account to Zookeeper. We only need to add a management account under the Zookeeper startup file, and then start Zookeeper:
add the above red line"-Dzookeeper.DigestAuthenticationProvider.superDigest = Account: Password"Such as super administrator we add is: super:123456:
As if we get the ciphertext password for the account, the above also introduced the
The above is based on the windows environment. The steps to add a super administrator account in the Linux environment are similar. You only need zkServer.shto modify it in the file, and I wo n’t repeat it here.
