Zookeeper权限访问控制简介及实操

近日在某项目部署实施过程中，进行了线上漏洞扫描后，在出具的漏扫报告中存在一个需修复项“Zookeeper 未授权访问”。通过查询了解，得知需通过添加身份认证的方式来解决该修复项，在修复、验证以及后续应用上线的过程中，碰到了系列问题，特作记录分享。

一、 问题介绍

Zookeeper是分布式协同管理工具，常用来管理系统配置信息，提供分布式协同服务。Zookeeper以树状结构保存数据，znode是Zookeeper的基本单元，可以存放数据信息、版本信息等等。如下图，/是Zookeeper的根节点，A、B、C和D均为znode。

Zookeeper这样的树状结构，在默认情况下，只需要提供Zookeeper服务端的IP和Port信息，任何用户或者客户端都可以直接连接服务端，不需要任何额外的认证，就拥有对znode增、删、改、查、管理等操作权限。这样的访问方式是非常不安全，比较容易受到攻击和数据的篡改。

二、 Zookeeper使用ACL进行访问控制

鉴于存在这样的安全隐患，Zookeeper通过ACL(Access Control List)的机制来解决这个问题。当客户端连接到Zookeeper并且做认证的时候，Zookeeper验证所有从连接的服务端收集到的id，当服务端试图访问不同的znode节点时，将通过ACL来做验证。

ACL是由(scheme:expression, perms)对构成，expression的格式为如下内置schemes：

a. world 有一个特定的的id, anyone，代表所有人。

b. auth 不使用任何id，代表任何已认证的用户。

c. digest 用 username:password 字符串来产生一个MD5串，然后该串被用来作为ACL ID。认证是通过明文发送username:password 来进行的，当用在ACL时，表达式为username:base64 ，base64是password的SHA1摘要的编码。

d. ip 使用客户端的主机IP作为ACL ID 。

Perms的格式为如下操作权限：

a. CREATE：可以创建子节点，缩写为C;

b. DELETE：可以获取节点下的数据以及目录下的列表，缩写为D;

c. WRITE：可以在节点中写入数据，缩写为W;

d. DELETE：可以删除子节点，缩写为D：

e. ADMIN：可以设置权限，缩写为A;

这里有一点需要注意的是，ACL只适用于当前节点，它是非递归的，而且是不可递归的。比如/aaa节点对用户aaa只读，但是/aaa/bbb节点，对所有用户来说是world的认证方式。

三、 Zookeeper权限配置

通过文档了解后，拟尝试使用digest的认证方式作为漏洞的修复手段。

首先登录Zookeeper控制台，如下图所示：

获取当前目录权限：

由于该服务器是已修复的，因此显示的是digest认证的信息。

重新在根目录下创建目录：

从这个步骤可以看出，ACL的认证是非递归的，即使根目录的权限是digest，创建的子目录权限仍然是world。

下图通过setAcl的命令来设置新目录的权限，并且查看是生效的。

当登录后未使用digster认证时，就会提示权限不足。

四、 应用调用修改

既然提供服务的Zookeeper增加了认证，那么调用的java程序也是需要进行同步修改的。

按公司应用的结构，只需要添加对应配置即可。

另外在调试过程中发现，公司使用的第三方jar包zkclient.jar的版本是0.1，是不支持ACL的，需更换成高版本2.0即可。

作者介绍

陈旭，资深应用维护工程师，毕业于浙江大学软件工程学院，通过ITIL认证。先后在互联网创业公司、地方电子口岸任职。主要负责中间件运维和自动化运维工具研发，致力于提升运维服务的规范性和应用服务的高可用性。