每一个成功人士的背后,必定曾经做出过勇敢而又孤独的决定。
放弃不难,但坚持很酷~
版本说明: 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特点可以分为以下几点:
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
,即所有人都拥有这五个权限,按顺序分别为:
zookeeper的ACL Schemes有以下几种:
acl的相关命令如下表所示:
命令 | 使用方式 | 描述 |
---|---|---|
getAcl | getAcl <path> | 读取ACL权限 |
setAcl | setAcl <path> <acl> | 设置ACL权限 |
addauth | addauth <scheme> <auth> | 添加认证用户 |
通过以下命令进入zookeeper cli模式,默认连接localhost
。
zookeeper创建的节点默认的权限就是world:anyone:cdrwa
,即所有人在client端都拥有cdrwa
这五个权限。如下图所示:
节点权限是world
,也就是默认权限,为所有client端开放,这样肯定是不安全的,我们先基于auth模式进行权限的控制。
为/test1节点增加auth权限认证方式。设置方式如下:
addauth digest <用户>:<明文密码> #添加认证用户
setAcl <path> auth:<user>:<acl>
客户端示例:
小结:
Authentication is not valid : /test1
。设置方式如下:
setAcl <path> digest:<用户>:<密文>:<acl>
digest加密模式相对于auth来说要稍微麻烦一些,需要对明文密码进行BASE64(SHA1(password))的处理。
如何对password进行加密,有两种方法:
第一种方法:这里的密码是经过SHA1及BASE64处理的密文,在shell中可以通过以下命令计算:
echo -n <user>:<password> | openssl dgst -binary -sha1 | openssl base64
生成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
执行效果如下图所示:
客户端示例:
小结:
Authentication is not valid : /test2
。digest 与 auth 模式之间的不同:
设置方式如下:
setAcl <path> ip:<ip>:<acl>
<ip>:可以是具体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
。
该模式属于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