zookeeper 权限管理

znode节点操作

znode是Zookeeper的数据节点，znode之间是类似于目录树的结构关系，对Zookeeper的操作一般都是对znode的操作，而对znode节点操作就是一般的crud操作。

# znode节点操作部分
　　create \[-s\] \[-e\] path data acl　　# 创建一个znode节点，同时设置节点权限acl，-s表示创建有序节点，-e创建临时节点，如创建一个/mynode节点：create /mynode hello，另外znode需要按照层级去创建，如创建/node1/node2，需要县创建/node1再创建/node1/node2
　　stat path \[watch\]　　             # 查看znode状态，如数据长度，时间戳等等，同时可以注册一个监听器
　　get path \[watch\]　　              # 获取znode节点的数据，同时可以注册一个监听器，如：get /mynode
　　set path data \[version\]　　       # 设置znode的数据，同时可以设置一个监听器，如：set /mynode "hello world"
　　ls path \[watch\]　　               #列出znode的子节点，同时可以设置一个监听器，如：ls /
　　ls2 path \[watch\]　　              #列出znode的子节点，同时可以设置一个监听器，如：ls2 /，与ls的区别是ls2还可以获取到子节点个数等等状态信息
　　delete path \[version\]　　         #删除znode节点，注意路径为绝对路径，且不可删除拥有子节点的znode
　　rmr path　　                        #递归删除znode节点，与delete的区别是可以删除拥有子节点的znode

quota配额操作

quota配额机制就是对znode做一些限制，支持节点个数和空间大小（字节数）两种方式，不过貌似quota配额并不会阻止操作的进行，而只是抛出警告　　

    # quota配额
　　setquota -n|-b val path　　#增加配额，-n是设置子节点的配额数量，-b是设置节点内容的长度
　　listquota path              #列出节点配额信息
　　delquota \[-n|-b\] path    #删除节点配额

ACL权限控制

　　当使用zkCli连接Zookeeper时，就是和Zookeeper集群开启了一次会话，而acl操作就是对会话权限进行控制的操作　　

    #ACL权限控制
    setAcl path acl　　#`给已有节点赋予权限，其中acl是权限`  
　　 getAcl path　　#查看节点的权限  
　　 # 在上面的创建节点操作中，我们也可以给节点赋予权限，如：

　　Zookeeper的acl权限由[scheme : id :permissions]三部分组成，其中scheme是认证类型，id一般指的是账号，也就是权限所针对的对象，permissions表示对节点的空权限类型，而scheme和permissions有以下可选项：　　

Permissions可选项

在使用时，可以使用首字母进行简写（crwda）：
CREATE：允许创建子节点；
READ：允许从节点获取数据并列出其子节点；
WRITE：允许为节点设置数据；
DELETE：允许删除子节点；
ADMIN：允许为节点设置权限。

Scheme可选项

world：默认模式，所有客户端都拥有指定的权限。world下只有一个id选项，就是anyone，通常组合写法为world:anyone:[permissons]；比如：setAcl /mynode world:anyone:crwda
auth：只有经过认证的用户才拥有指定的权限。通常组合写法为auth:user:password:[permissons]，使用这种模式时，你需要先进行登录，之后采用auth模式设置权限时，user和password都将使用登录的用户名和密码；比如：setAcl /mynode auth:feng:123456:crwda
digest：只有经过认证的用户才拥有指定的权限。通常组合写法为digest:user:BASE64(SHA1(password)):[permissons]，这种形式下的密码必须通过SHA1和BASE64进行双重加密；比如：setAcl /mynode digest:feng:xHBaNtDKjaz0G0F0dq11735c9r8=:crwda
ip：限制只有特定IP的客户端才拥有指定的权限。通常组成写法为ip:182.168.0.168:[permissions]；比如：setAcl /mynode ip:192.168.28.213:crwda
super：代表超级管理员，拥有所有的权限，需要修改Zookeeper启动脚本进行配置。

auth模式和digest模式其实是一样的

区别可以理解为，auth模式使用的是明文密码，而digest使用的是密文密码（SHA1和BASE64）,比如下面两种方式是等价的
　　 setAcl /mynode auth:feng:123456:crwda
　　 setAcl /mynode digest:feng:xHBaNtDKjaz0G0F0dq11735c9r8=:crwda
　　 #这里说的等级是在使用setAcl命令为znode添加权限控制时，并非在使用addauth添加认证时

　　一般的，权限是给znode节点设置的，当使用zkCli连接到Zookeeper开启一个会话时，默认情况下是world认证模式，该模式下只能操作那些world认证模式权限的znode节点，要访问某个特定模式下的节点，就需要满足节点上设置的认证模式。

ip模式

　　super模式用的少，一般可以忽略，ip模式即指定客户端，比如：　　

    setAcl /mynode ip:192.168.209.134:crwda

这个表示当我们从192.168.209.134访问时才能访问到/mynode节点，否则会提示Authentication is not valid

[zk:192.168.209.133:2181(C0NNECTED) 0] getAcl /mynode
'world,'anyone
：cdrwa
[zk: 192.168.209.133:2181(C0NNECTED) 1] setAcl /mynode ip:192.168.209.134:crwda
cZxid=0x70000005c
ctime = Mon May 18 16:55:27 CST 2020
mZxid=0x70000005c
mtime = Mon May 18 16:55:27 CST 2020
pZxid=0x70000005c
cversion =θ
dataVersion =0
aclVersion = 4
ephemeral0wner=0x0
datalength = 11
numChildren =θ
[zk: 192.168.209.133:2181(C0NNECTED) 2] get /mynode
Authentication is not valid :/mynode
[zk:192.168.209.133:2181(C0NNECTED) 3]

然后我们到192.168.209.134上使用zkCli连接Zookeeper，发现成功访问到/mynode节点

[zk:192.168.209.134:2181(C0NNECTED) 0] getAcl /mynode
'ip.'192.168.209.134
：cdrwa
[zk:192.168.209.134:2181(C0NNECTED) 1] get /mynode
hello world
cZxid=0x70000005c
ctime = Mon May 18 16:55:27 CST 2020
mZxid=0x70000005c
mtime = Mon May 18 16:55:27 CST 2020
pZxid=0x70000005c
cversion =0
dataVersion =θ
aclVersion = 4
ephemeral0wner=0x0
datalength = 11
numChildren =θ
[zk:192.168.209.134:2181(C0NNECTED)2]

登录认证

　　对于auth模式和digest模式，就需要修改当前会话的认证模式，修改认证模式使用addauth命令：　　

addauth scheme auth
#scheme是认证模式（貌似只能是digest），auth是认证信息，格式：user:password  
  
例如：
 addauth digest feng:123456
 #添加auth模式，后面携带的参数user:password模式  
#如果要退出认证，只需要使用close关闭连接，再使用connect重新连接就好了　　

简单解释一下acl权限的auth模式（digest模式）设置过程，假如我们开启一个新的会话，我们有一个/mynode节点：

[zk:localhost:2181(CoNNECTED) 0] getAcl /mynode
'world,'anyone
：cdrwa
[zk:localhost:2181(C0NNECTED) 1]

可以看到，/mynode节点默认模式是world:anyone:cdrwa，然后我们修改它的权限：

[zk:localhost:2181(C0NNECTED) 63]addauth digest feng:123456[zk:localhost:2181(C0NNECTED)64]setAcl/mynode auth:feng:123456:ra
cZxid=0x70000005c
ctime = Mon May 18 16:55:27 CST 2020
mZxid=0x70000005c
mtime = Mon May 18 16:55:27 CST 2020
pZxid=θx70000005c
cversion =θ
dataVersion =θ
aclversion =1
ephemeral0wner =0xθ
dataLength = 11
numchildren = θ
[zk:localhost:2181(CoNNECTED) 65] getAcl /mynode
digest,*feng:xHBaNtDKjaz0G0F0dq11735c9r8=
：ra
[zk:localhost:2181(C0NNECTED) 66]

从上面可以看到，只有feng:123456这个用户可以读（r），还可以管理权限（a），其他认证都不能操作数据节点，

注意，当我们需要修改znode节点的acl时，需要确认我们当前会话已使用addauth命令添加了认证信息，否则会提示设置acl权限失败（所以上图第一行命令addauth就是添加认证信息）

[zk:localhost:2181(c0NNECTED) 61] setAcl /mynode auth:feng:123456:ra
Aclis not valid:/mynode

退出登录

　　接着，我们使用close命令关闭连接，使用connect命令重新连接，这时会话就变成了无认证状态，使用get获取/mynode节点数据时就会提示认证错误：

　　接着我们添加认证信息，然后再使用get命令就可能获取到数据了

　　总结：acl权限控制可以理解为，在创建znode节点时或者使用setAcl命令为已存在的znode添加Scheme模式（world，auth，digest，ip，super）和权限（crdwa），Scheme模式作为匹配条件，当客户端连接Zookeeper的会话满足Scheme模式的条件，就会具有此znode节点上设置的权限

其他命令操作

    history    #查看当前会话中使用过的命令，每个命令会携带一个编号
    redo cmdno    #重新执行命令，cmdno是命令编号，可以使用history查看
    printwatches \[on|off\]    #是否输出 watch 事件，如果使用on或者off则表示设置  
　　 sync path　　#会强制客户端所连接的服务器状态与leader的状态同步，这样在读取 path 的值就是最新的值了  
　　 quit　　#直接退出当前的zkCli命令行  
　　 close 　　#关闭连接，但不会退出当前zkCli命令行  
　　 connect host:port　　#打开连接

本文转自 https://www.cnblogs.com/shanfeng1000/p/12700144.html，如有侵权，请联系删除。

znode节点操作​

quota配额操作​

ACL权限控制​

Permissions可选项​

Scheme可选项​

auth模式和digest模式其实是一样的​

ip模式​

登录认证​

退出登录​

其他命令操作​