对zookeeper设置ACL属性

对zookeeper设置ACL属性

我们以zkCli为例，来说明zookeeper对ACL的设置。

使用zkCli时，ACL的格式由<schema>:<id>:<acl>三段组成。

注意：zookeeper对权限的控制是znode级别的，不具有继承性，即子节点不继承父节点的权限。这种设计在使用上还是有缺陷的，因为很多场景下，我们还是会把相关资源组织一下，放在同一个路径下面，这样就会有对一个路径统一授权的需求。

这是默认方式，表示没有认证。当创建一个新的节点(znode)，而又没有设置任何权限时，就是这个值，例如：

看到/noacl的ACL属于就是world schema的，因为它没有设置ACL属性，这样任何人都可以访问这个节点。

如果要手工设置这个属性，那么此时的id域只允许一个值，即anyone，格式如下：

这种授权不针对任何特点ID，而是对所有已经添加认证的用户，换句话说，就是对所有已经通过认证的用户授权。

用法如下：

注意:

举例：

这个例子中，我们先添加了三个认证用户tom1,tom2,tom3，然后通过setAcl设置ACL，命令中指定了id为tom2，根据前面的说法，这个id值是被忽略的，写任何值，甚至空值也得到一样的结果。我们看到最后getAcl查询出来的结果包含所有前面添加的三个认证用户。

补充说明：zkCli的命令 addauth digest user:pwd 是用来添加当前上下文中的认证用户的：

其实我不是很理解这个功能，难道在一个会话(session)里可以添加多个认证用户吗，那验证的时候按哪一个算呢；如果不同的用户有不同的授权会导致授权冲突吗？以谁为准？

几点总结：

所以这种授权方式更倾向于用作测试开发环境，而不是产品环境中。

这就是最普通的用户名:密码的验证方式，在一般业务系统中最常用。

格式如下：

和schema auth相比，有两点不同：

密码可以通过如下shell的方式生成：

例如：

或者可以使用zookeeper的库文件生成：

输出的 root:jalRr+knv/6L2uXdenC93dEDNuE= 就是传递给setAcl使用的id串。

注意，只有通过zkCli.sh设置digest的ACL时id才需要密文，而通过zookeeper的客户端设置digest的ACL时对应的auth数据是明文。这个属于编码实现的问题了。

和auth比较，digest有如下特性：

就是客户机地址，或者是主机名、或者是IP地址。

主机名可以是单个主机名，也可以是域名。IP可以是单个IP地址，也可以是IP地址段，比如ip:192.168.1.0/16。

这个不细说了，比较简单，也没有验证过。

设置一个超级用户，这个超级用户的设置必须在zookeeper内部，zookeeper启动之前设置好。在这种scheme情况下，超级用户具有超级权限，可以做任何事情(cdrwa)，不需要授权。

5.1 设置zookeeper环境变量SERVER_JVMFLAGS：

5.2 重启zookeeper

创建/test节点，并且设置acl为jerry1用户。

5.3 添加认证用户tom

5.4 访问节点/test

这时失败，因为tom用户没有权限。

5.3 添加认证用户root

5.4 再次访问节点/test

成功，虽然root也没有在/test的acl列表里面(是有jerry1)，但是也能访问，因为root在zookeeper集群里面被配置成了超级用户。

CREATE、READ、WRITE、DELETE、ADMIN 也就是 增、删、改、查、管理权限，这5种权限简写为crwda(即：每个单词的首字符缩写)

注：这5种权限中，delete是指对子节点的删除权限，其它4种权限指对自身节点的 *** 作权限

Zookeeper的ACL通过scheme:id:permissions来构成权限

scheme这边主要用到4种方式：

world：默认方式，相当于全世界都能访问

auth：代表已经认证通过的用户(cli中可以通过addauth digest user:pwd 来添加当前上下文中的授权用户)

digest：即用户名:密码这种方式认证，这也是业务系统中最常用的

ip：使用Ip地址认证

这次项目让设置一下dubbo连接zookeper的权限问题，于是看到了设置ACL权限，找到zookeeper下的bin文件夹，打开zk服务，启动./zkCli.sh

如果在dubbo中没有指定分组的话，dubbo会默认生成一个分组dubbo，也就是在zookeeper下面会有个子节点dubbo

1）增加一个认证用户

addauth digest 用户名:密码明文

eg：addauth digest user1:password1

2）设置权限

setAcl /path auth:用户名:密码明文:权限

eg. setAcl /test auth:user1:password1:cdrwa

3）查看Acl设置

getAcl /path

在添加用户之前，查看一下zookeper的节点信息，然后创建一个新的节点用来添加用户（使用绝对路径 要添加数据）

如果不加之前配置的认证用户

setAcl /path digest:用户名:密码密文:权限

注：这里的加密规则是SHA1加密，然后base64编码。

经过上面的过程结果还是不能绕过zookeeper未授权访问漏洞，经测试可以在其他服务器上通过echo envi|nc + ip + 端口 访问到zk的信息

因为zookeeper会默认启动这几个具有world和cdrwa权限的znode，“/” "/zookeeper" "/zookeeper/config"和"/zookeeper/quota"（根据zookeeper的版本不同可能存在不同，并且这几个节点虽然具有world和cdrwa权限，但是是无法删除的，不知道为什么，好在我们可以给它设置ACL列表。另外，官网对着几个节点也没有特别说明，估计和zk本身的一些配置相关吧，不删除最好）。就是这几个znode，会导致你的产品无法通过安全工具的漏洞扫描，解决办法也是很简单的，用我们前面说过的zk.setACL为这几个节点设置权限就OK了，千万别忘记根节点"/"了。

这里之所以设置完zookeeper节点还要设置quota

是因为 znode的ACL是相互独立的 。也就是说，任意不同节点可以用不同的acl列表，互不影响，并且 ACL是不可被继承的 。

好了，到这里，才是真正的解决了这个未授权访问漏洞问题了。

找到zookeeper的日志地址，把日志删除就行了，或者 delete /节点

linux环境下也可以使用命令,查询日志地址

参考博客：

https://blog.csdn.net/hekf2010/article/details/78844609

https://blog.csdn.net/wuxintdrh/article/details/73433283

https://www.cnblogs.com/ilovena/p/9484522.html

---