ZooKeeper使用ACL进行访问控制

ZooKeeper使用ACL控制节点的访问,ACL的实现类似于UNIX文件的访问许可:使用位来控制节点访问的作用域和访问许可。但不同于UNIX文件系统,对于标准的作用域,包括user(文件的拥有者),group和world(其它),ZooKeeper节点没有限制。Zookeeper没有znode的拥有者的概念,取而代之,ACL指定一套id和对应这些id的许可。
注意一个ACL仅和一个特定的znode有关,并且不传递到孩子节点,例如,如果/app是仅被ip:172.16.16.1可读,/app/status是world可读,那么任何人都能读/app/status;ACL不是递归的。
ZooKeeper支持可插拔式的认证方案。id使用scheme:expression的形式,scheme是id对应的认证方案,expression的有效集合被scheme定义,例如,ip:172.16.16.1是一个id,scheme是ip,expression是主机地址172.16.16.1;digest:bob:password也是一个id,scheme是digest,expression是用户名为bob的用户。
当一个客户端连接到ZooKeeper进行认证时,ZooKeeper获取与该客户端有关的所有id。当客户端尝试连接到一个节点时,ZooKeeper使用节点的ACL对这些id进行检查。ACL的形式为(scheme:expression, perms),expression的格式由scheme决定,例如,(IP:19.22.0.0/16,READ)表示对所有起始IP为19.22的客户端具有读权限。

ACL权限

ZooKeeper支持以下的权限:

  • CREATE:拥有创建孩子节点的权限;
  • READ:拥有获取节点数据和孩子列表的权限;
  • WRITE:拥有设置节点数据的权限;
  • DELETE:拥有删除节点数据的权限;
  • ADMIN:拥有设置权限的权限。
    将CREATE和DELETE许可从WRITE许可中分离出来,是为了做到更细粒度的访问控制。考虑下面的场景:
  • 你想A能为ZooKeeper节点设值,但不能CREATE和DELETE孩子。
  • 有CREATE权限但无DELETE权限的情景:客户端在父节点上通过发送创建请求创建一个ZooKeeper节点。你希望所有客户端都能在这个节点上添加,但是只有创建者能够删除(类似于文件的APPEND权限)。
    ADMIN权限存在是由于zookeeper没有文件所有者的概念。在某种意义上说,ADMIN权限指定了所谓的所有者。zookeeper虽然不支持 查找权限(在目录上的执行权限虽然不能列出目录内容,却可以查找),但每个客户端都隐含着拥有查找权限。这样你可以查看节点状态,但仅此而已。(这有个问 题,如果你在不存在的节点上调用了zoo_exists(),你将无权查看)。

内置ACL方案

ZooKeeper有下面的内置方案:
- world:有独立id,anyone,代表所有人;
- auth:不使用任何id,表示任何已认证的用户;
- digest:使用了格式为username:password的字符串生成一个MD5哈希表作为ACL ID,在空文档中发送username:password来完成认证。现在的ACL表达式格式为username:base64,用SHA1编码密码;
- ip:用客户端IP作为ACL ID。ACL表达式的格式为addr/bits,addr中最有效的位匹配客户端主机IP最有效的位;
- x509:用客户端X500 Principal作为ACL ID,ACL表达式是客户端的X500 Principal名称。当使用安全端口时,客户端被自动认证,并且他们的认证信息被设置。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页