zookeeper ACL permissions

Original link: https://www.jianshu.com/p/392248ab27f4

Set ACL property for zookeeper

We zkCli example to illustrate the zookeeper set the ACL.

When using zkCli, ACL format by the <schema>: <id>: <acl> three sections.

• schema: you can take the following values: world, auth, digest, host / ip
• id: ID of identity, value depends on the schema do to resolve.
• acl: it is the privilege: cdwra respectively, create, delete, write, read, admin

Note: zookeeper control authority is znode level, not inherited, that is a child node does not inherit parent permissions. This design is still in use flawed, because in many scenes, we will look at organizational resources, following in the same path, so there will be a path to a unified authorization requirements.

1. schema world

This is the default mode, that there is no certification. When you create a new node (znode), but do not set any permissions, is this value, for example:

[zk: localhost:2181(CONNECTED) 18] create /noacl 'noacl' Created /noacl [zk: localhost:2181(CONNECTED) 19] getAcl /noacl 'world,'anyone : cdrwa 

See / noacl the ACL is part of the world schema, because it does not set the ACL property, so anyone can access the node.

To manually set this property, then the time of the id field allows only one value, i.e. the anyone, in the following format:

setAcl /newznode world:anyone:crdwa

2. schema auth

This authorization is not directed against any characteristics of ID, but have been added to all authenticated users, in other words, all the user has authorized certified.

Usage is as follows:

addauth digest <user>:<password> setAcl <path> auth:<id>:<acl> 

note:

• 1. You need to add authentication than user, otherwise it will fail. As follows:

[zk: localhost:2181(CONNECTED) 0] create /test 'test'
[zk: localhost:2181(CONNECTED) 1] setAcl /test auth::crdwa
Acl is not valid : /test

• 2. setAcl id field of the command is ignored, any value can fill, or empty string, for example: `setAcl <path> auth :: crdwa. Because this field is ignored, all authenticated users will have to add all add to the mix.

For example:

[zk: localhost:2181(CONNECTED) 2] addauth digest tom1:tom1 [zk: localhost:2181(CONNECTED) 3] addauth digest tom2:tom2 [zk: localhost:2181(CONNECTED) 4] addauth digest tom3:tom3 [zk: localhost:2181(CONNECTED) 5] setAcl /test auth:tom2:crdwa [zk: localhost:2181(CONNECTED) 6] getAcl /test 'digest,'tom1:ben+k/3JomjGj4mfd4fYsfM6p0A= : cdrwa 'digest,'tom2:2iJM00A7+qkeKdEXt8Bhgq+IACw= : cdrwa 'digest,'tom3:TAZPWLs6IaYRS8mlvcfyCOwyBJ8= : cdrwa 

This example, let's add three to authenticate the user tom1, tom2, tom3, and then set the ACL by setAcl, the id specified in the command is tom2, according to the previous statement, the id value is ignored, write any value, even null also get the same result. We see the last getAcl check out the results contain three to authenticate the user to add all of the preceding.

Supplement: zkCli command addauth digest user:pwdis used to authenticate the user to add the current context:

addauth digest user1:password1(明文) 

In fact, I do not really understand this feature, you can do add multiple user authentication in a session (session) in it, verify that the time by which count it; if different users have different authorization would cause authorization to conflict? Who to prevail?

Some Summary:

1. auth id value is invalid, the setting is acl permissions to all authenticated users.
   1.1 authenticating a user to add, by addauth command (addauth digest <username>: < password>), valid only during the current session (the session).
2. After you add multiple authentication when users addauth command, and then auth setAcl to set acl, then all users will be before addauth have been added to the acl.
3. If you fail in the current session has not been authenticated user on the use of auth setAcl permission to set acl, we discussed earlier.

[zk: localhost:2181(CONNECTED) 1] setAcl /test auth::crdwa
Acl is not valid : /test

4. After auth setAcl reuse addauth add user authentication is no acl rights and must be repeated auth setAcl to set permissions.
5. Addauth user authentication using only add the current session (session) effective, if at this time in another session, user, the authentication was not added, there is no appropriate access rights, and privileges to set when you use a acl auth setAcl, acl permission before it will cover the information, but only to set acl permissions for the authenticated user in the current session.

So this License prefer as a test development environment rather than a production environment.

3. schema digest

This is the most common username: password authentication, in general business systems most commonly used.
Format is as follows:

setAcl <path> digest:<user>:<password(密文)>:<acl> 

And schema auth compared with two exceptions:

1. The first advance is not required to add user authentication (but when zkCli visit, be sure to add or authenticated user).
2. The second code is processed through sha1 and base64 ciphertext.

Password may be generated by way of shell:

echo -n <user>:<password> | openssl dgst -binary -sha1 | openssl base64 

E.g:

echo -n root:root | openssl dgst -binary -sha1 | openssl base64
qiTlqPLK7XM2ht3HMn02qRpkKIE=

Or you can use zookeeper library file generation:

java -cp /zookeeper-3.4.13/zookeeper-3.4.13.jar:/zookeeper-3.4.13/lib/slf4j-api-1.7.25.jar \ org.apache.zookeeper.server.auth.DigestAuthenticationProvider \ root:root root:root->root:qiTlqPLK7XM2ht3HMn02qRpkKIE= 

Output root:jalRr+knv/6L2uXdenC93dEDNuE=is transmitted to the string id setAcl used.

setAcl /test2 digest:root:jalRr+knv/6L2uXdenC93dEDNuE=:rwdca 

Note that only the ciphertext need be provided through the ACL zkCli.sh digest of id, and the corresponding setting of the digest of an ACL client zookeeper auth plaintext data. This problem belongs to a coded implementation.

And auth comparison, digest has the following characteristics:

1. setAcl do not need to add to authenticate the user in advance.
2. Authorization is specific for a single user.
3. Password is not expressly setAcl use sha1 digest value is not anti-user password to launch content.

4. schema host/ip

That is the client address or host name or IP address.
The host name can be a single host name, or domain name. IP can be a single IP address, IP addresses may be, for example ip: 192.168.1.0/16.
This is not elaborate, simple, and no verified.

5. super user

Set a super user, this super user settings must be within the zookeeper, zookeeper before the start set. In this scheme, the super user with root privileges, you can do anything (cdrwa), no license is required.

5.1 zookeeper set environment variables SERVER_JVMFLAGS:

export SERVER_JVMFLAGS="-Dzookeeper.DigestAuthenticationProvider.superDigest=root:qiTlqPLK7XM2ht3HMn02qRpkKIE="

5.2 Restart zookeeper

Create / test node, and to set acl jerry1 users.

[zk: localhost:2181(CONNECTED) 0] create /test 'test'
Created /test
[zk: localhost:2181(CONNECTED) 1] setAcl /test digest:jerry1:dJJW56m9FIOfUDDHVC5wVWNsFEo=:rwdca
[zk: localhost:2181(CONNECTED) 2] getAcl /test
'digest,'jerry1:dJJW56m9FIOfUDDHVC5wVWNsFEo=
: cdrwa

5.3 Adding user authentication tom

[zk: localhost:2181(CONNECTED) 3] addauth digest tom:tom 

5.4 Access Node / test

[zk: localhost:2181(CONNECTED) 4] get /test Authentication is not valid : /test 

In this case failed because the user does not have permission tom.

5.3 Add to authenticate the user root

[zk: localhost:2181(CONNECTED) 6] addauth digest root:root 

5.4 again access node / test

[zk: localhost:2181(CONNECTED) 6] get /test
test
...

Success, although there is no root in acl / test list (there jerry1), but can also be accessed because the root is configured to become the superuser zookeeper cluster inside.