zookeeper ACL 权限控制 | ━Start。平常心

版本说明：

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，即所有人都拥有这五个权限，按顺序分别为：

Create：允许对子节点Create操作
Delete：允许对子节点Delete操作
Read：允许对本节点GetChildren和GetData操作，有对本节点进行删除操作的权限。
Write：允许对本节点SetData操作
Admin：允许对本节点setAcl操作

三、访问控制列表方案（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的相关命令如下表所示：

命令	使用方式	描述
getAcl	getAcl \	读取ACL权限
setAcl	setAcl \ \	设置ACL权限
addauth	addauth \ \	添加认证用户

通过以下命令进入zookeeper cli模式，默认连接localhost。

1. world 模式

zookeeper创建的节点默认的权限就是world:anyone:cdrwa，即所有人在client端都拥有cdrwa这五个权限。如下图所示：

节点权限是world，也就是默认权限，为所有client端开放，这样肯定是不安全的，我们先基于auth模式进行权限的控制。

2. auth 模式

为/test1节点增加auth权限认证方式。设置方式如下：

1 2	addauth digest <用户>:<明文密码> #添加认证用户 setAcl <path> auth:<user>:<acl>

客户端示例：

小结：

首先，需要创建用户上下文 – addauth，密码为明文密码。
其次设置权限 – setAcl
查看节点权限的时候，密码会自动转为密文，该密文是采用user:BASE64(SHA1(password))的字符串。
查看节点数据之前，必须确保拥有认证用户的上下文，否则会报：Authentication is not valid : /test1。

3. digest 模式

设置方式如下：

1	setAcl <path> digest:<用户>:<密文>:<acl>

digest加密模式相对于auth来说要稍微麻烦一些，需要对明文密码进行BASE64(SHA1(password))的处理。

如何对password进行加密，有两种方法：

第一种方法：这里的密码是经过SHA1及BASE64处理的密文，在shell中可以通过以下命令计算：

1	echo -n <user>:<password> \| openssl dgst -binary -sha1 \| openssl base64

生成lyz:create17对应的加密密文，如下图所示：

切记：生成的是lyz:create17对应的密文，如果将lyz换为其它，密文则不一样。

第二种方法：使用zookeeper提供的java类来生成密文：

1
2

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 认证模式

设置方式如下：

1	setAcl <path> ip:<ip>:<acl>

：可以是具体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行，注意前后空格。具体如下图所示：