ZooKeeper访问控制列表(ACL)
摘自《apache zookeeper essentials》
ZooKeeper数据模型提供了一种机制，就是使用ACL去控制访问znode的ACL。在创建znode的时候，ACL就决定了你对znode的权限相关的各种操作。ZooKeeper的ACL模型和linux/unix中的文件权限中允许和阻止操作相似，通过设置权限位作用在znode上。但是Zookeeper中没有linux和unix文件中所有者的观念。ACL决定了ZooKeeper Service与客户端的认证机制
ZooKeeper提供了以下基于ACL的内置的认证机制:
- World: 任何人都可以连接到
ZooKeeper Service - Auth: 任何已经认证的user,但不使用ID
- Digest 基于用户名和密码的认证
- IP Address 基于客户端IP地址的认证
除了以上涉及的认证模式，ZooKeeper还支持可插拔式(pluggable)的认证机制,这使用在需要的时候可以集成第三方认证。ZooKeeper中任何认证机制者由下面两个操作组成:
- 首先，ZooKeeper是基于客户端的认证架构，当客户端连接到
ZooKeeper Service时通过校验客户端信息产生客户端的认证 - 其次，认证架构找到
ACL中与客户端绑定的entries，ACL是一组由<IDs,Permissions> pairs组成的,IDs就是校验客户端的字符串
关于znodeACL中重要的一点，ACL相关的znode是不会传播到它的子结点的。ZooKeeper的客户端认证是可选的，ACL就是认证机制，认证的身份和一组权限的组合
ZooKeeper中ACL支持的权限:
| Operation | ACL Permissioin |
|---|---|
| CREATE | 创建znode的子结点 |
| READ | 获取znode的子结点和znode上的数据 |
| WRITE | 对znode设置数据 |
| DELETE | 删除znode子结点 |
| ADMIN | 设置ACL的权限 |
任何连接到ZooKeeper Service的客户端都有权限去校验znode的存在性，exist操作是无需权限的，这就使得可以去检索znode的统计结构(the stat structure of a znode)。ZooKeeper中内置了一些预定义的ACL:
| ACL | Description |
|---|---|
| ANYONE_ID_UNSAFE | ID代表任何人 |
| AUTH_IDS | 可以设置ACL,代替了已经认证过客户端的IDs |
| OPEN_ACL_UNSAFE | 表示完全开放的ACL，授于了除ADMIN以外的所有权限 |
| CREATOR_ALL_ACL | 创建znode的权限 |
| READ_ACL_UNSAFE | 给于world的能力去读数据 |