Hadoop源码解析之: HBase Security

艾辉

文不打算对这部分代码进行全面的解读，而是先对几个主要类的职能进行概述，然后再罗列一些有价值的重要细节。本文原文连接：http://blog.csdn.net/bluishglc/article/details/11903613 转载请注明出处！

• 第一部分：HBase Security 概述
  

HBase Security主要是基于User和User Group（Role）对表（或是更细粒度的Family、Qualifer）进行安全检查（目前HBase Security暂不支持基于行的安全检查，但后续版本中会追加进来）。在authentication方面，它主要是通过Kerberos来完成的，这部分不是HBase Security实现的重点，HBase Security的大部分代码是在解决authorization的问题，也就是根据用户权限判定其是否有权访问某项资源。




HBase Security主要有这样几个重要的类：




org.apache.hadoop.hbase.security.access.AccessController




这是对所有访问进行拦截的入口，它既是MasterObserver又是RegionObserver，言下之意，它能拦截所有的操作。




org.apache.hadoop.hbase.security.access.AccessControlLists




这是专门负责对Permission进行读写（包括数据库和ZooKeeper）操作的类，你可以认为这一个DAO或是Repository




org.apache.hadoop.hbase.security.access.TableAuthManager




这是负责对用户进行权限检查的类，它主要有多个重载的authorize方法组成。同时，由于这个类的实例cache了所用的permission，因此它还有一些借助ZKPermissionWatcher进行同步本地与ZooKeeper数据的工作。



org.apache.hadoop.hbase.security.access.ZKPermissionWatcher




这是一个专门监视_acl_节点的一个ZooKeeper的Watcher. HBase Security在设计上为了考虑性能，会把所有的permission加载到内存中，但是如果permission发生变化，各节点需要同步这些变化，因此将所有的permission写入到ZooKeeper，然后再通过一个“观察者”实时监控并更新permission，这个“观察者”就是KPermissionWatcher。




补充一句：从代码上看，TableAuthManager和ZKPermissionWatcher两个类耦合过于紧密，彼此互为对方的field. 此处的设计并不好，其实可以将两者合二为一，让TableAuthManager实现ZooKeeperListener。

• 第二部分：若干重要细节
  

以下是一些有价值的细节问题，有关于配置部署的，有关于代码实现的。




1. 打开安全检查的方式是注册一些安全相关的coprocessor, 具体做法是在所有节点的hbase-site.xml中加入以下内容重启集群, 其中指定rpc engine为SecureRpcEngine

是因为该引擎能传递remote client传递的用户凭证(如用户名..),安全检查是以用户提供的凭证为基础进行的.

<property>
<name>hbase.rpc.engine</name>
<value>org.apache.hadoop.hbase.ipc.SecureRpcEngine</value>
</property>
<property>
<name>hbase.coprocessor.master.classes</name>
<value>org.apache.hadoop.hbase.security.access.AccessController</value>
</property>
<property>
<name>hbase.coprocessor.region.classes</name>
<value>org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.AccessController</value>
</property>

2. 打开安全机制前,最好指定一个superuser, 否则在刚打开安全机制时,_acl_表为空,意味着任何用户都无法从事任何操作,所以需要使用superuser来为用户分配权限.指定superuser的方法是在hbase-site.xml中加入:
<property>
<name>hbase.superuser</name>
<value>superuser-accout: such as root</value>
</property>

3. 存储权限数据的表：_acl_ 的schema



4. 表的owner,也就是建表账户将自动拥有对该表的所有操作权限:RWXCA. 参见方法:
org.apache.hadoop.hbase.security.access.RowBasedAccessController.postCreateTable(...)

5. 用户或组的权限可以指定到 <table> <column family> <column qualifier> 三种不同的层次（粒度）上. 通过试验表明, 下层权限会自动继承上层权限!,.如给一个sample表R的权限,column family:cf也是R的权限,而qualifier:q是W的权限,那么用户即能读取也能写入cf:q.

6. 紧接第4点，考虑一种更为复杂的情况：

假定sample表有100个qualifier, 100个qualifier分属多个family,假定没有指定sample表级别的读权限，但是通过对多个family和family下的qualifier设定读权限，其中80个qualifier已经具备了读权限，那么，当该用户执行scan 'sample' 操作时，结果会如何呢？通过试验表明，所有具备读权限的qualifier都列出了，所有没有读权限的qualifier都被过滤掉了。 这是一种合理的处理方式，而关于这部分的处理逻辑是通过在权限检查时通过org.apache.hadoop.hbase.security.access.AccessControlFilter进行过滤实现的。这个Filter其实也非常简单，它是主要是通过org.apache.hadoop.hbase.security.access.TableAuthManager.authorize(User, byte[], KeyValue, Action)进行最细度（精确的 qualifier)的检查，只有确定有权读写的qualifier才会通过检查，否则就被过滤掉。

7. Permission的Class Hierarchy:

Permission (包含了Action)
|
|--TablePermission (又包含了table,family,qualifier)
|
|--UserPermission(又包含了user)

8. 关于 cache:

AccessController在初始化的时候会load所有的permission,然后写到zookeeper里.参考:org.apache.hadoop.hbase.security.access.AccessController.initialize(RegionCoprocessorEnvironment)

同时, 一个ZooKeeper的监听器ZKPermissionWatcher会关注 ZooKeeper的任何变化,当Permission数据写入zookeeper时,方法org.apache.hadoop.hbase.security.access.ZKPermissionWatcher.nodeDataChanged(String)
会被触发,这个方法会负责把前面刚刚写入的Perssmion加载到缓存里!

Cache分为两类: 表级Cache和全局Cache. 表级Cache是一个以表名为Key,以这个表对应的<用户,权限>对为Value的Map, 而全局Cache 是指那些不针对某个具体表的全局Permission, 所以它的结构是一个<用户,权限>对组成的map. 关于全局Cache一个重要的细节是: 很显然, 所有的superuser是应该放在全局cache里,而且应被赋予所有权限.(参考:org.apache.hadoop.hbase.security.access.TableAuthManager.initGlobal(Configuration))

表级Cache:

TABLE_USER_CACHE: Map<TableName,Map<UserName,Permission>>
TABLE_GROUP_CACHE: Map<TableName,Map<UserName,Permission>>

全局Cache:

USER_CACHE:Map<USerName,Permission>
GROUP_CACHE: Map<TableName,Map<UserName,Permission>>

cache隶属于一个TableAuthManager实例, 而TableAuthManager是一个管理多个自身实例的单态, 它维护一个全局的map,这个map里一个ZooKeeperWatcher实例对应一个它的实例. 参考:org.apache.hadoop.hbase.security.access.TableAuthManager.get(ZooKeeperWatcher, Configuration)

9. ZooKeeperListener的典型应用案例:ZKPermissionWatcher

security的一个设计需求是:,所有region和master对应的coprocessor所依赖的authManager都需要加载所有的permission到cache里,通过内存中permission实例进行权限检查. security的实现方式是:当_acl_表对应的region open的时候,加载所有的permission(参考AcessController(L720-L723),当所有的permission加载之后,就把它们再写到zookeeper节点上,参考org.apache.hadoop.hbase.security.access.AccessController.initialize(RegionCoprocessorEnvironment).
而由于所有的 authManager 实例都含有一个ZKPermissionWatcher,这是一个ZooKeeperListener, 当zookeeper节点上的数据发生变化时,这个watcher的nodeCreated方法会被触发,进而重新加载permission数据!

10. 关于AccessController和TableAuthManager与ZooKeeperWatcher的实例数量
对于AccessController来说,做为MasterObserver时, 会创建一个实例.作为BaseRegionObserver来说, 一个region(不是region server)会创建一个是实例!而TableAuthManager与ZooKeeperWatcher的实例是一一对应的,参考:
org.apache.hadoop.hbase.security.access.TableAuthManager.get(ZooKeeperWatcher, Configuration)
而ZooKeeperWatcher的实例自来于Master或Region启动( MasterObserver 的start方法和BaseRegionObserver的postOpen)时从MasterServices或RegionServerServices中取得的ZooKeeper的实例!而这个ZooKeeper实例是一个server(node)对应一个. 所以对于同一个regionserver上的所有region,引用的是同一个zookeeper实例.