zookeeper ACL usage

In a production environment, there are often multiple projects using zookeeper, such as multiple hbase clusters. Each project builds a set of independent zookeepers, which is an additional overhead in terms of machine cost and operation and maintenance cost.

However, multi-project and multi-cluster sharing of zookeeper involves a problem of permission isolation. zookeeper itself provides an ACL mechanism, expressed as scheme:id:permissions, the first field indicates which mechanism is used, and the second id indicates

User, permissions represent related permissions ( CREATE, READ, WRITE, DELETE, ADMIN are the permissions to add, delete, modify, check, and manage, these five permissions are abbreviated as crwda ).

 

Zookeeper provides the following mechanisms (schemes):

• world : There is only one id under it, called anyone, representing anyone
• auth : It does not require an id, as long as the authenticated user has authority (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:password first
• ip : its corresponding id is the IP address of the client. You can set an ip segment when setting it, such as ip:192.168.1.0/16, which means the IP segment that matches the first 16 bits
• super : In this case, the corresponding id has super permission and can do anything (cdrwa)

 

The following demonstrates an example of setting ACL for the created node through digest (username and password):

 

 

import org.apache.zookeeper.*;
import org.apache.zookeeper.server.auth.DigestAuthenticationProvider;
import org.apache.zookeeper.data.*;
import java.util.*;

public class NewDigest {

    public static void main(String[] args) throws Exception {

        // new acl
        List<ACL> acls = new ArrayList<ACL>();
        // Add the first id, in the form of username and password
        Id id1 = new Id("digest",
                DigestAuthenticationProvider.generateDigest("admin:admin "));
        ACL acl1 = new ACL(ZooDefs.Perms.ALL, id1);
        acls.add(acl1);
        // add a second id, all user-readable permissions
        Id id2 = new Id("world", " anyone");
        ACL acl2 = new ACL(ZooDefs.Perms.READ, id2);
        acls.add(acl2);

        // zk authenticates with admin and creates /test ZNode.
        ZooKeeper zk = new ZooKeeper(
                "host1:2181,host2:2181,host3:2181",

        zk.addAuthInfo("digest", "admin:admin".getBytes());
        zk.create("/test", "data".getBytes(), acls, CreateMode.PERSISTENT);
  }
}

However, after all, ACL is only access control, not perfect permission management. There are many limitations in doing multi-cluster isolation in this way:

(1) ACL does not have a recursive mechanism. After any znode is created, it needs to set the ACL separately, and cannot inherit the ACL settings of the parent node.

(2) In addition to the scheme of ip, the use of digest and auth is not transparent to users, which also brings a lot of cost to the use. Many open source frameworks that rely on zookeeper do not add support for ACL, such as hbase, storm