【zookeeper】ACL

Zookeeper ACL的实现和UNIX的文件访问权限十分相似，它采用权限位去允许或禁止对节点的各种操作，包括节点的位范围。但与UNIX的文件访问权限不同的是，ACL不能基于创建者、创建者所在的组和其它用户组分配不同的权限，ACL没有Znode的权限拥有者，相反，ACL指定一系列的权限位和Ids并将它们关联起来使用

ACL权限(ACL Promissions)：

CREATE ：可以创建一个子节点
READ：可以获取节点内容或者子节点列表
WRITE：可以设置节点内容
DELETE：可以删除子节点
ADMIN：可以设置权限

ACL权限模式(ACL Schemes)：

WORLD：对应唯一id即anyone
DIGEST：id为username:passworld模式，zookeeper会加密成username:base64(SHA1(passworld))保存
IP:id为ip

使用cli命令来体验一下(以digest权限模式为例)

首先创建了节点 /bar ，默认的权限模式为world，id为anyone，权限位为cdrwa
通过  setAcl /node scheme:id:权限位的格式  给该/bar节点设置了权限位为admin、create、权限类型为digest、id为foo:y1xaDUoc4rBi9lBzy27i2+rcMWs=的权限
通过  getAcl来获取节点信息发现没有权限
通过  addauth scheme id给客户端添加了/bar节点权限认证信息
通过  get命令正常获取/bar节点信息

继续来给/bar创建一个/bar/1子节点，创建失败，发现没有权限，因为此时的/bar节点权限为ar(admin、read)
修改/bar节点的权限设置为ac(admin、create)
给客户端添加ac认证
创建bar/1子节点成功

此时/bar节点的权限为ac(admin、create)，子节点/bar/1的权限为(cdrwa)
继续获取子节点/bar/1节点信息成功，获取/bar节点失败，说明了子节点的控制权限范围超出了父节点的范围
继续删除子节点/bar/1失败，设置/bar节点权限为ad(admin、delete)，给客户端添加ad认证，然后删除子节点/bar/1成功，删除节点/bar成功，说明了节点的delete权限是对删除子节点起作用

下面来看看 zookeeper服务端是如何对客户端进行认证的：
首先在zookeeper的安装目录bin下的zkServer.sh的140行加入-agentlib:jdwp=transport=dt_socket,address=9009,server=y,suspend=n后启动zookeeper进行远程debug
然后通过客户端中创建一个父节点/qwert及子节点/1，然后给父节点加上如下权限

接下来给客户端添加delete认证信息后执行节点/1的删除动作
在PrepRequestProcessor的run方法中加入debug断点，进入pRequest方法中的caset OpCode.delete 选项中，接着进入pRequest2Txn的checkACL中，

参数acl为父节点的权限，pertm为执行的动作，ids为客户端的认证id信息，关于pertm动作的各个值对应如下

如果是super超级用户则能直接通过认证，接下来会依次遍历节点的权限上的权限位，如果所有权限上的权限位上都没有包含客户端执行动作，那么认证失败，如果权限上的权限位包含了执行的动作，那么接下来会去判断客户端的认证是否是一个超级用户，如果是则直接通过认证，如果不是，就会去和客户端添加的认证信息id进行比对。其中还需要关注的点是AuthenticationProvider ap = ProviderRegistry.getProvider(id.getScheme())，也就是说在进行比对的时候会根据节点设置权限的scheme寻找到对应的AuthentionProvider由它来进行比对，来看看它里面具体的逻辑

逻辑很简单，会去系统属性找到带有zookeeper.authProvider.的键的值(也可以在zoo.cfg中配置authProvider.=来设置，它是怎么被加载进来的我也没去找，自己去找吧，嘿嘿)，好了，知道这个原理了我们可以自己来实现一个自定义scheme的权限啦，

来看看AuthenticationProvider接口的一些方法，目前我们可以关注getScheme()和matches()两个方法，此scheme()方法的返回值要和客户端添加认证信息的scheme一致，不然一定会认证失败，在matches方法里面你可以拥有你自己的算法，当然这个算法和你在添加节点一致哈，说实际点就是在添加acl的时候你可以先sha1、base64后再加上自己的算法，再matches里面比对的时候zookeeper会默认的对客户端填入的id认证信息进行sha1、base64加密， 你在matches方法里面只需要对从客户端传过来的i进行你自己的加密算法后和节点上的权限进行比对即可。万事俱备，只欠东风，自定义好的AuthenticationProvider部署在哪里呢，是客户端还是服务端?恩，肯定是服务端呀，来看看zookeeper安装目录bin下文件zkEnv.sh的73行

明白了吧，把你实现好的AuthenticationProvider打成一个jar包放在src/java/lib下即可。

关于digest模式下的super id：

根据ACL权限控制的原理，一旦对一个数据节点设置了ACL权限控制，那么其他没有被授权的Zookeeper客户端无法访问该数据节点，这的确很好的保证了Zookeeper的数据安全，但同时ACL权限控制也给zookeeper的运维人员带来了一个困扰：如果一个持久数据节点包含了ACL权限控制，而其创建者客户端已经退出或者不再使用，这个时候，就需要在ACL的super模式下使用超级管理员权限来进行处理了，开启super模式需要在zookeeper服务器启动的时候添加以下系统属性：

-Dzookeeper.DigestAuthenticationProvider.superDigest=username:password