zookeeper的ACL权限

对于ZooKeeper，开发人员往往负责管理访问控制的权限，而不是管理员。fuck，程序员真苦逼。

ACL是做什么的

ZooKeeper通过访问控制表（ACL）来控制访问权限。一个ACL包括以下形式的记录：<scheme：auth-info>

scheme：一组内置的鉴权模式。

auth-info：鉴权模式对应的鉴权信息。

如果创建节点时设置了访问权限，那客户端操作节点时有什么不一样呢？你需要带该节点需要的鉴权信息，表明我是自己人，才会让你操作节点。如果没有提供鉴权信息，或者鉴权信息与要请求的znode节点的鉴权信息不匹配，就会收到一个权限错误。

客户端可以在任何时候调用addAuthInfo来添加鉴权信息。一般情况下，在ZooKeeper句柄创建后就会调用该方法来添加鉴权信息。当然可以多次调用该方法，为一个ZooKeeper句柄添加多个权限的身份。

子节点并不会继承父节点的访问权限。2者的acl并没有什么卵子关联。

常用的ACL有哪几种

1、world作为鉴权模式

这种就是内置的ZOO_OPEN_ACL_UNSAFE 和 ZOO_READ_ACL_UNSAFE所用的策略，使用world作为scheme，使用anyone作为auth-info，对于world这种鉴权模式，只能使用anyone这种auth-info。

2、super作为鉴权模式

这种是管理员所使用的super模式，该模式不会被列入到任何ACL中，但可以用于ZooKeeper的鉴权。一个客户端通过super鉴权模式连接到ZooKeeper后，不会被任何节点的ACL所限制。因为权限过大，尔等屌丝程序员一般接触不到，不做过多描述。

3、digest作为鉴权模式

该模式的auth-info格式为  userid:passwd_digest，使用digest 作为scheme，userid:passwd_digest作为auth-info。其中userid为用户名，passwd_digest为用户密码的 摘要信息。至于这个摘要 由什么算法怎么生成的，貌似是先sha1，在对sha1结果base64.

4、ip作为鉴权模式
因为需要通过客户端的地址来进行ACL策略的检查，这种需要提供网络的地址和掩码，不需要调用addAuthInfo方法。server配置好就可以。

不常用的玩意

1、SASL和Kerberos

SASL表示简单认证与安全层（Simple Authentication and SecurityLayer）。SASL将底层系统的鉴权模型抽象为一个框架，因此应用程序可以使用SASL框架，并使用SASL支持多各种协议。在ZooKeeper中，SASL常常使用Kerberos协议。在使用SASL模式时，使用sasl作为模式名，id则使用客户端的Kerberos的ID。SASL是ZooKeeper的扩展鉴权模式，因此，需要通过配置参数或
Java系统中参数激活该模式。因为没用过，鬼知道怎么配置。

2、增加新鉴权模式

ZooKeeper中还可以使用其他的任何鉴权模式。对于激活新的鉴权模式来说只是简单的编码问题，需要去搞java源码，我TM........

总结

个人遇到最常用的还是 world作为鉴权模式和 digest作为鉴权模式，其他的也没闲工夫去研究。都是严格的内网，貌似ZOO_OPEN_ACL_UNSAFE用的最多，O(∩_∩)O