阅读本文大约需要5分钟
版本说明：
zookeeper：3.4.6
一、概述
zooKeeper使用acl（Access Control List）来控制对其znode（zooKeeper数据树的数据节点）的访问。 不过，zookeeper的acl并不像HDFS系统的acl一样，可以递归控制权限。zookeeper的acl不是递归的，仅适用于特定的znode。比如/app这个znode，设置一些权限，只能某用户可以访问，但是/app/status的权限是与/app没有关系的，默认是world:anyone:cdrwa。
总的来说。zookeeper的acl特点可以分为以下几点：
zooKeeper的权限控制是基于每个znode节点的，需要对每个节点设置权限。每个znode支持设置多种权限控制方案和多个权限。多种权限控制方案以逗号分隔，例如：setAcl /hiveserver2 sasl:hive:cdrwa,world:anyone:r。子节点不会继承父节点的权限，客户端无权访问某节点，但可能可以访问它的子节点。二、权限类型
当客户端连接到zooKeeper并对其自身进行身份验证，当客户端尝试访问znode节点时，将检查znode的acl。 acl由（scheme:expression:permission）对组成，表达式的格式特定于scheme。例如，该对（ip:19.22.0.0/16:r）为任何IP地址以19.22开头的客户端提供READ权限。
zookeeper默认所有节点都是world:anyone:cdrwa，即所有人都拥有这五个权限，按顺序分别为：
三、访问控制列表方案（ACL Schemes）
zookeeper的ACL Schemes有以下几种：
world：只有一个id即anyone，为所有Client端开放权限。auth：不需要任何id，只要是通过auth的用户都有权限。digest：Client端使用用户和密码的方式验证，采用username:BASE64(SHA1(password))的字符串作为节点ACL的id（如：digest:lyz:apNZxQYP6HbBQ9hRAibCkmPKGss=）。ip：使用客户端的IP地址作为ACL的id，可以设置为一个ip段（如：ip:192.168.0.1/8）。Client端由IP地址验证，譬如172.2.0.0/24。sasl：设置为用户的uid，通过sasl Authentication用户的id，在zk3.4.4版本后sasl是通过Kerberos实现（即只有通过Kerberos认证的用户才可以访问权限的znode），使用sasl:uid:cdwra字符串作为节点ACL的id（如：sasl:lyz:cdwra）。四、示例
acl的相关命令如下表所示：
通过以下命令进入zookeeper cli模式，默认连接localhost。
1. world 模式
zookeeper创建的节点默认的权限就是world:anyone:cdrwa，即所有人在client端都拥有cdrwa这五个权限。如下图所示：
节点权限是world，也就是默认权限，为所有client端开放，这样肯定是不安全的，我们先基于auth模式进行权限的控制。
2. auth 模式
为/test1节点增加auth权限认证方式。设置方式如下：
addauth digest : #添加认证用户
setAcl <path> auth:<user>:
/<user>/<path>
客户端示例：
小结：
首先，需要创建用户上下文 — addauth，密码为明文密码。其次设置权限 — setAcl查看节点权限的时候，密码会自动转为密文，该密文是采用user:BASE64(SHA1(password))的字符串。查看节点数据之前，必须确保拥有认证用户的上下文，否则会报：Authentication is not valid : /test1。3. digest 模式
设置方式如下：
setAcl <path> digest:::
/<path>
digest加密模式相对于auth来说要稍微麻烦一些，需要对明文密码进行BASE64(SHA1(password))的处理。
如何对password进行加密，有两种方法：
第一种方法：这里的密码是经过SHA1及BASE64处理的密文，在shell中可以通过以下命令计算：echo -n <user>:<password> | openssl dgst -binary -sha1 | openssl base64
/<password>/<user>
生成lyz:create17对应的加密密文，如下图所示：
切记：生成的是lyz:create17对应的密文，如果将lyz换为其它，密文则不一样。
第二种方法：使用zookeeper提供的java类来生成密文：export ZK_CLASSPATH=/etc/zookeeper/conf/:/usr/hdp/current/zookeeper-server/lib/*:/usr/hdp/current/zookeeper-server/*
java -cp $ZK_CLASSPATH org.apache.zookeeper.server.auth.DigestAuthenticationProvider lyz:create17
执行效果如下图所示：
客户端示例：
小结：
首先，获取密码加密后的密文然后可直接setAcl设置权限，不用添加身份认证如果要访问节点数据，必须确保拥有认证用户的上下文，再访问节点数据，否则会报：Authentication is not valid : /test2。digest 与 auth 模式之间的不同：
auth采取明文认证的模式，在对节点设置权限之前，需要先设置认证用户的上下文。访问节点数据也是同理。digest采取密文认证的模式，可以直接对节点设置权限。当访问节点数据时，也需要提前设置认证用户的上下文。4. ip 认证模式
设置方式如下：
setAcl <path> ip::
/<path>
：可以是具体IP也可以是IP/bit格式，即IP转换为二进制，匹配前bit位，如192.168.0.0/16匹配192.168.*.*
客户端示例：
如上图所示，对/test3节点设置10.6.6.71全部权限，10.6.6.72可读权限。使用localhost访问/test3，自然是不可行的。接下来在10.6.6.71与72节点上测试一下：
在10.6.6.72节点进入zkCli模式，执行以下命令：
/usr/hdp/3.0.1.0-187/zookeeper/bin/zkCli.sh -server 10.6.6.72
在10.6.6.73节点进入zkCli模式，访问/test3数据，会报：Authentication is not valid : /test3。
5. sasl 模式
该模式属于kerberos所特有的模式，需要依赖kerberos实现。只有通过Kerberos认证的用户才可以访问权限的znode。设置权限的方式，比如：setAcl /hiveserver2 sasl:hive:cdrwa。
五、设置超级管理员
假如你忘记了你认证用户的密码，或者基于其它什么情况，导致某znode节点无法被操作，怎么办呢？其实我们可以为zookeeper设置超级管理员。
用户:密码还是以lyz:create17为例：
1.首先还是要获取lyz:create17的密文，这里就不赘述了，密文为：lyz:apNZxQYP6HbBQ9hRAibCkmPKGss=。
2.编辑/usr/hdp/3.0.1.0-187/zookeeper/bin/zkServer.sh，添加一些配置。
将"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" "-Dzookeeper.DigestAuthenticationProvider.superDigest=lyz:apNZxQYP6HbBQ9hRAibCkmPKGss="添加至文件的第135行，注意前后空格。具体如下图所示：
3.保存文件，重启该节点上的zookeeper服务。这样，zookeeper的超级管理员就设置成功了。
4.执行命令进入zkCli模式：/usr/hdp/3.0.1.0-187/zookeeper/bin/zkCli.sh，再执行addauth digest lyz:create17认证身份，这样就具备超级管理员角色，可以操作任意节点了。
六、总结
本篇文章主要介绍了zookeeper的acl操作，介绍了acl的权限类型，还有acl的Schemes。主要是对Schemes如何使用进行了示例说明。
zookeeper的acl不支持级联操作，即子节点不会继承父节点的权限。这样就导致了修改节点权限比较麻烦，可能这种设计模式也有它的优点吧。如果有对这一方面了解的朋友，欢迎告知，谢谢。
更多acl知识，可参考zookeeper官网：https://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#sc_ZooKeeperAccessControl
--END--
码字不易，如果您觉得文章写得不错，请关注作者~ 您的关注是我写作的最大动力
友情提示：原文排版精美，可点击分享链接查看。