集群启用Kerberos后对Zookeeper的Znode操作异常分析

温馨提示：要看高清无码套图，请使用手机打开并单击图片放大查看。

Fayson的github：https://github.com/fayson/cdhproject

提示：代码块部分可以左右滑动查看噢

1.问题描述

在CDH集群中Zookeeper已启用Kerberos服务，在命令行为使用Kerberos账号进行Kinit操作，使用zookeeper-client登录后仍然可以进行创建znode和删除znode，并且可以删除其它有服务的Znode，具体操作如下：

[root@ip-172-31-30-69 ~]# klist
klist: No credentials cache found (filename: /tmp/krb5cc_0)
[root@ip-172-31-30-69 ~]# echo $CLIENT_JVMFLAGS
[root@ip-172-31-30-69 ~]# zookeeper-client -server ip-172-31-16-68.ap-southeast-1.compute.internal

（可左右滑动）

Zookeeper-client连接成功

在Zookeeper-client命令行执行命令创建、浏览、查看及删除znode操作

create /zk-test-anyone data
ls /zk-test-anyone
getAcl /zk-test-anyone
rmr /zk-test-anyone
ls /

（可左右滑动）

2.Zookeeper的ACL权限说明

ZooKeeper使用ACL来控制对znodes（ZooKeeper数据树的数据节点）的访问。ACL权限如下：

CREATE：可以创建子节点（c）。

READ：可以获取该节点的数据，也可以读取该节点所有的子节点数据(r)。

WRITE：可以写数据到该节点(w)。

DELETE：可以删除子节点(d)。

ADMIN：可以在该节点中设置权限(a)。

Zookeeper的內建ACL Schema有如下：

world：只有一个id即anyone，ACL权限设置方式即为（world:anyone）代表任何人，在ZK中把任何人都有权限访问的节点归属为world:anyone。

auth:不需要任何ID，只要是通过auth的用户都有权限。

digest:使用用户和密码的方式验证，采用username:BASE64(SHA1(password))的字符串作为节点ACL的ID（如：digest:hdfs-fcs:+yC2mfwpV9AJntm8TYfc7+e4EUg=）。

ip:使用客户端的IP地址作为ACL的ID，可以设置为一个IP段（如：ip:192.168.0.1/8）

sasl:设置为用户的uid，通过sasl Authentication用户的ID，在zk3.4.4版本后sasl是通过Kerberos实现（即只有通过Kerberos认证的用户才可以访问权限的znode），使用sasl:uid:cdwra字符串作为节点ACL的ID（如：sasl:fayson:cdwra）。

3.ACL权限控制测试

这里以world和sasl两种方式来实现znode的ACL权限控制来说明前面的问题。

1. 在不使用Kerberos账号Kinit的前提下，直接使用Zookeeper-client访问Zookeeper

[root@ip-172-31-30-69 ~]# klist
klist: No credentials cache found (filename: /tmp/krb5cc_0)
[root@ip-172-31-30-69 ~]# echo $CLIENT_JVMFLAGS
[root@ip-172-31-30-69 ~]# zookeeper-client -server ip-172-31-16-68.ap-southeast-1.compute.internal

（可左右滑动）

创建一个/zktest-world的zonde，并设置ACL权限为world:anyone:cdrwa，操作如下：

create /zktest-world data world:anyone:cdwra
ls /
ls /zktest-world
getAcl /zktest-world
rmr /zktest-world
ls /

（可左右滑动）

2.不使用Kerberos账号Kinit的前提下，使用zookeeper-client登录Zookeeper服务

[root@ip-172-31-30-69 ~]# klist
klist: No credentials cache found (filename: /tmp/krb5cc_0)
[root@ip-172-31-30-69 ~]# echo $CLIENT_JVMFLAGS
[root@ip-172-31-30-69 ~]# zookeeper-client -server ip-172-31-16-68.ap-southeast-1.compute.internal

（可左右滑动）

创建一个/zktest-sasl的zonde，并设置ACL权限为sasl:fayson:cdrwa，操作如下：

create /zktest-sasl data sasl:fayson:cdrwa
ls /zktest-sasl
rmr /zktest-sasl
getAcl /zktest-sasl

（可左右滑动）

可以看到设置ACL为fayson用户后无法正常访问与删除/zktest-sasl，接下来使用jaas.conf文件进行认证登录Zookeeper

zk-cli-jaas.conf文件的内容如下,由于我们创建的/zktest-sasl指定的用户为fayson，所以这里我们使用fayson的keytab用户加载：

[root@ip-172-31-30-69 ~]# vim zk-cli-jaas.conf 
Client {
   com.sun.security.auth.module.Krb5LoginModule required
   useKeyTab=true
   keyTab="/root/fayson.keytab"
   storeKey=true
   useTicketCache=false
   principal="fayson@FAYSON.COM";
};

（可左右滑动）

加载zk-cli-jaas.conf文件到CLIENT_JVMFLAGS环境变量，然后再使用zookeeper-client访问ZK服务：

[root@ip-172-31-30-69 ~]# export CLIENT_JVMFLAGS="-Djava.security.auth.login.config=/root/zk-cli-jaas.conf"
[root@ip-172-31-30-69 ~]# zookeeper-client -server ip-172-31-16-68.ap-southeast-1.compute.internal

（可左右滑动）

查看和删除/zktest-sasl

ls /zktest-sasl
rmr /zktest-sasl
ls /

（可左右滑动）

4.CDH中依赖ZK服务的Znode ACL权限问题

在启用Kerberos前，各服务已向Zookeeper服务注册，所以这些Znode默认是没有使用ACL权限控制的，在集群启用Kerberos后，由于Znode节点已在Zookeeper服务中存在，所以依赖ZK服务的各个组件并未重新向ZK服务注册，导致已存在ZK服务的Znode无ACL权限控制，导致前面提到的问题。

解决方法：登录Zookeeper服务将无ACL的Znode删除并重启相应服务即可，部分服务如HBase、Solr需要做一些操作才可以是起Znode启用ACL权限控制。

配置Solr和HBase服务重新创建带有ACL权限的Znode

• 通过zookeeper-client登录ZK删除/solr和/hbase的Znode
• 登录CM进入HBase服务修改HBase配置，启用Kerberos认证

• 进入Solr服务，停止Solr服务并初始化ZK

完成如上操作后，重启HBase和Solr服务即可，查看Zookeeper的中/solr和/hbase的ACL权限

5.问题总结

• Zookeeper服务针对所有用户均可以访问，但对应的Znode需要有相应权限的用户才可访问或操作。
• 如果需要自己的Znode带有ACL权限则在创建Znode时需要指定对应的访问权限，在CDH中各个服务如果启用了Kerberos则需要服务支持向ZK创建带有ACL权限的Znode。
• 在启用Kerberos环境下的ZooKeeper，如果需要删除服务（如：hive、hbase、hdfs等）注册信息时，需要先获取到该目录的ACL权限，根据ACL权限使用不同服务的keytab文件kinit后进行删除，否则会报“Authentication is not valid”问题。

提示：代码块部分可以左右滑动查看噢

为天地立心，为生民立命，为往圣继绝学，为万世开太平。 温馨提示：要看高清无码套图，请使用手机打开并单击图片放大查看。

推荐关注Hadoop实操，第一时间，分享更多Hadoop干货，欢迎转发和分享。