zookeeper ACL使用

 生产环境中，常常会有多个项目使用zookeeper，例如多个hbase集群。每一个项目搭建一套独立的zookeeper，不管从机器成本，仍是运维成本，都是一笔额外的开销。

然而多项目，多集群共用zookeeper又涉及一个权限隔离的问题。zookeeper自己提供了ACL机制，表示为scheme:id:permissions，第一个字段表示采用哪种机制，第二个id表示

用户，permissions表示相关权限（如只读，读写，管理等）。zookeeper提供了以下几种机制（scheme）：

• world: 它下面只有一个id, 叫anyone, world:anyone表明任何人，zookeeper中对全部人有权限的结点就是属于world:anyone的
• auth: 它不须要id, 只要是经过authentication的user都有权限（zookeeper支持经过kerberos来进行authencation, 也支持username/password形式的authentication)
• digest: 它对应的id为username:BASE64(SHA1(password))，它须要先经过username:password形式的authentication
• ip: 它对应的id为客户机的IP地址，设置的时候能够设置一个ip段，好比ip:192.168.1.0/16, 表示匹配前16个bit的IP段
• super: 在这种scheme状况下，对应的id拥有超级权限，能够作任何事情(cdrwa）

下面演示一个经过digest（用户名密码的方式）为建立的节点设置ACL的例子：

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 { // TODO Auto-generated method stub //new一个acl List<ACL> acls = new ArrayList<ACL>(); //添加第一个id，采用用户名密码形式 Id id1 = new Id("digest", DigestAuthenticationProvider.generateDigest("admin:admin")); ACL acl1 = new ACL(ZooDefs.Perms.ALL, id1); acls.add(acl1); //添加第二个id，全部用户可读权限 Id id2 = new Id("world", "anyone"); ACL acl2 = new ACL(ZooDefs.Perms.READ, id2); acls.add(acl2); // zk用admin认证，建立/test ZNode。  ZooKeeper zk = new ZooKeeper( "host1:2181,host2:2181,host3:2181", 2000, null); zk.addAuthInfo("digest", "admin:admin".getBytes()); zk.create("/test", "data".getBytes(), acls, CreateMode.PERSISTENT); } }

 然而，ACL毕竟仅仅是访问控制，并不是完善的权限管理，经过这种方式作多集群隔离，还有不少局限性：

（1）ACL并没有递归机制，任何一个znode建立后，都须要单独设置ACL，没法继承父节点的ACL设置。

（2）除了ip这种scheme，digest和auth的使用对用户都不是透明的，这也给使用带来了很大的成本，不少依赖zookeeper的开源框架也没有加入对ACL的支持，例如hbase，storm