ZooKeeper安全认证机制:ZNode ACL

ZooKeeper的Client-Server互认证机制是从3.4.0版本开始引入的,本文主要介绍znodes的ACL的定义,任务服务接口定义与几种已有的认证服务实现,以及ACL与多种认证服务是如何建立联系的。本文内容基于ZooKeeper 3.5.1版本。

ACL

ZooKeeper的ACL可针对znodes设置相应的权限信息。ACL数据的表示格式为:schema​:id:​permissions

  • schema     支持的几种schema为:
    • world

    只有一个名为anyoneId, world:anyone代表任何人,也就是说,对应节点任何人可访问

    • auth

    代表任何通过认证的用户,该schema不需要配置Id信息

    • digest

    基于username:password生成的MD5 Hash值作为Id信息,认证基于username:password明文认证,但在acl中存储的是username:base64(password)

    • ip

    基于IP地址作为Id,支持IP地址或IP地址段

  • id    代表用户
  • permissions    权限定义为(READ, WRITE, CREATE, DELETE, ADMIN, ALL)

由ACL的定义信息,可以看出来,ZooKeeper可以针对不同的znodes来提供不同的认证机制。

AuthenticationProvider

每一种认证服务均需要实现AuthenticationProvider接口来支持一种新的schema,所有的AuthenticationProvider实现类都被注册在ProviderRegistry中。ZooKeeper中已经提供的AuthenticationProvider`的实现类:
AuthenticationProvider实现类
每一个AuthenticationProvider实现类所关联的schema如下所示:

AuthenticationProvider实现类 schema
DigestAuthenticationProvider digest
IPAuthenticationProvider ip
SASLAuthenticationProvider sasl
X509AuthenticationProvider x509

当znode acl schema为world时,是不需要经任何AuthenticationProvider进行认证的,因此不需要任何实现类。
当znode acl schema为auth时,代表着需要对请求上下文中的认证信息进行校验,在ServerCnxnauthInfo中保存了所有的已认证成功的Id以及认证服务所关联的的schema,由该schema再去ProviderRegistry中查找所关联的AuthenticationProvider实现类来对认证信息进行校验。
除了上述已有的实现者以外,用户还可以自定义实现AuthenticationProvider。自定义的实现类,需要设置到System Properties中,对应的Property Key需以"zookeeper.authProvider."开头。另外,自定义的AuthenticationProviderschema名称不应与现有的重名,否则会覆盖现有的实现。

Reference

  1. Client-Server Mutual Authentication
  2. ZOOKEEPER-938

本文源自:NoSQL漫谈(nosqlnotes.com)
除非特别注明,本站文章均为原创,转载请注明出处和链接。

推荐阅读:

ZooKeeper安全认证机制:SSL

ZooKeeper安全认证机制:用户名密码认证

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注