Zookeeper开发指南——权限控制&身份验证 _Zookeeper

今天小编分享一篇关于Zookeeper权限控制&身份验证的内容，内容主要是对官方文档的翻译，在翻译过程中加入了小编自己的理解，并使用比较容易理解的方式进行表述和修饰，希望能帮各位开发小伙伴更新容易理解相关的内容；小编之前也分享过Zookeeper相关的文档，可参考如下链接：

Zookeeper概览-官方文档翻译
Zookeeper开发者指南——Zookeeper数据模型
Zookeeper开发指南——Zookeeper会话
Zookeeper开发指南——Zookeeper监听

Zookeeper使用ACLs进行访问控制（ZooKeeper access control using ACLs）Zookeeper使用ACLs控制对节点的访问；ACL的实现与 UNIX 文件访问权限非常相似：它使用权限位来允许/禁止对节点的各种操作以及这些权限位适用的范围。但与标准 UNIX 权限不同，Zookeeper 节点不受“用户（文件所有者）”、“组”和“其他”三个标准范围的限制。Zookeeper 没有znode 所有者的概念。相反，ACL是指定一组 id 和与这些 id 关联的权限。
另外请注意，ACL仅适用于特定的znode，特别是不适用于子节点。例如：如果 /App 只能被 ip:172.16.16.1 读取，并且 /app/status的权限范围是所有人，那么任何人都可以读取 /app/status； ACL不是递归的。
ZooKeeper 支持插拔式的身份验证方案。使用scheme:expression格式来指定ID列表，其中 scheme 是ID对应的身份验证方案，有效的expression集合由scheme定义。例如，ip:172.16.16.1 是使用ip方案来指定的ID, 其中主机地址为 172.16.16.1，表示该IP地址的主机有权限，而 digest:bob:password 表示了用户名称为bob的digest方案对应的ID 。
当客户端连接到 ZooKeeper 并对其自身进行身份验证时，ZooKeeper 会将与客户端对应的所有 id 与客户端连接相关联。当客户端尝试访问节点时，这些 id 会根据 znode 的 ACL 进行检查。ACL 由成对的 (scheme:expression, perms) 组成。表达式的格式会根据方案不同而有所不同。例如，(ip:19.22.0.0/16, READ) 将 READ 权限授予 IP 地址以 19.22 开头的任何客户端。
ACL权限Zookeeper支持以下的权限:

CREATE: 开发者可以创建一个子节点
READ: 开发者可以获取节点的数据以及子节点列表
WRITE: 开发者可以为节点设置数据
DELETE: 开发者可删除一个子节点
ADMIN: 开发者拥有管理员角色，可以设置权限

CREATE 和 DELETE 权限已从 WRITE 权限中分离出来，以实现更精细的访问控制。CREATE 和 DELETE 的场景如下：
希望 A 能够在 ZooKeeper 节点上进行设置，但不能CREATE 或DELETE 子节点。
CREATE：客户端通过在父目录中创建 ZooKeeper 节点来创建请求。开发者希望所有客户端都可以添加节点，但只有请求处理器可以删除。
此外，由于 ZooKeeper 没有文件所有者的概念，因此就有了ADMIN 权限。在某种意义上，ADMIN 权限将实体指定为所有者。ZooKeeper 不支持 LOOKUP 权限（对目录执行权限位以允许开发者在无法列出目录的情况下进行 LOOKUP）。每个人都隐含地拥有 LOOKUP 权限。这允许开发者统计一个节点，但仅此而已，没有其他用途。（问题是，如果你想在一个不存在的节点上调用 zoo_exists()，则没有权限校验）
ADMIN 权限依照 ACL规定，也有特殊的用法：为了检索 znode的 ACL，用户必须具有 READ 或 ADMIN 权限，但如果没有 ADMIN 权限，DIGEST哈希值将被屏蔽掉。
内置 ACL 方案Builtin ACL SchemesZookeeper包含以下内置方案：ZooKeeeper has the following built in schemes: