ZooKeeper-ACL(Access control List)

前言

ZooKeeper作为分布式系统中重要的中间件，节点上会存储一些关键信息。如果权限没有控制好，就会带来很大的问题。下面，我来介绍一些ACL（控制访问列表）。

ACL的格式由< schema >:< id >:< acl >三段组成，下面依次介绍。

shema(认证模式)说明

ACL的格式由< schema >:< id >:< acl >三段组成，schema有以下格式：

• world：默认方式，相当于全世界都能访问
• auth：代表已经认证通过的用户(cli中可以通过addauth digest user:pwd 来添加当前上下文中的授权用户)
• digest：即用户名:密码这种方式认证，这也是业务系统中最常用的
• ip：使用Ip地址认证
• super：超级管理员 （知道有这个东西，但是我这里没有做测试）

id(账户)说明

这个是受认证模式的影响。

• anyone：当shema为world，必须是这个，不能换。
• username：BASE64(SHA1(password))：当shema为digest时，使用这种方式。
• ip：对应shema为ip时

至于auth为什么没有，后面会告知。

acl(权限)说明

• 权限是作用在每个znode上的。
• 权限总共有CREATE、READ、WRITE、DELETE、ADMIN，就是增删改查管理员，简写为crwda。
• 父权限与子权限相互独立（不像linux文件系统）。（有特殊情况）
• 删除权限、创建权限都是父对子权限，即父亲不具有删除权限，子就无法删除。

详细测试

1. world认证
   
   创建一个节点，默认的就是任何人具有所有权限。

手工赋予全部权限

这里是因为没有这个节点的原因。

2. auth认证
   首先使用命令 addauth digest username:password 在上下文中添加认证用户，然后给用户赋予权限。
   
   这里有几点需要注意下：

• 不加用户，直接setAcl会报错，错误内容：Acl is not valid
• 在赋予权限的时候，setAcl /abc auth🅰️crdwa中的A（也就是id），写不写都无所谓。即使你填写空，它也会把所有的认证用户加进来
• 认证用户只是在此次会话中有效，新的会话赋权信息会覆盖上一次赋权信息
• 赋予权限之后再加入用户，这些用户都是没有权限的

总结：这种方式可以理解为digest的一种简便方式，因为不需要密文。

3. digest认证
   这就是最简单的用户名密码认证，使用的比较广泛。
   格式如下：

setAcl <path> digest:<user>:<password(密文)>:<acl>

密文使用如下方式生成：

echo -n tom:tom1 | openssl dgst -binary -sha1 | openssl base64

密文生产另外一种方式：

使用用户名和密文方验证。

4. ip认证
   IP 模式表示有相同 IP 地址的任何用户，通过 IP 地址粒度来进行权限控制，例如配置了ip:192.168.0.110，即表示权限控制都是针对这个IP地址的。同时，IP 模式也支持按照网段的方式进行配置，例如ip:192.168.0.1/24表示针对192.168.0.*这个IP段进行权限控制。以下是使用 IP 模式的 setAcl 的语法：

setAcl /<node-name> ip:<IPv4-address>:<permission-set>

下面使用127.0.0.1测试：

好文推荐：https://cloud.tencent.com/developer/article/1544294