生產環境中，經常會有多個項目使用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