HBase的权限控制
HBase自带的权限管理工具：
HBase的权限管理包括两个部分，分别是Authentication&Authorization
Authentication：针对某host是否有权成为集群的regionserver或者client端；
Authorization：是针对client端对集群数据的读写等权限；
其中Authentication由kerberos提供解决方案，用户级别的Authorization由ACL模块控制
（一）、Authentication——
kerberos的基本原理：
kerberos实现了机器级别的安全认证，包括服务器到服务器的认证，确保不会有其他机器冒充regionserver。kerberos中包含一个中心服务器（KDC），KDC中有数据库，由管理员将集群中确定的机器手动添加到上述数据库中，在KDC上会分别产生主机与各节点的keytab，并将这些keytab分发到对应的节点上。通过这些keytab文件，节点可以从KDC上获得与目标节点通信的秘钥，进而被目标节点所认证，从而才能提供相应的服务；
HBase的kerberos安装流程简述：
1、配置kerberos server和kerberos client
kerberos server既KDC，kerberos client是我们集群节点；
这一步安装kerberos的基本组件，包括krb5-libs、krb5-server等，并初始化kerberos数据库，添加admin用户等等；
2、配置hadoop
创建keytab并修改core-site.xml、hadoop-env.sh、hdfs-site.xml，主要是添加keytab文件的位置信息，并使能kerberos控制；
3、配置zookeeper
创建keytab，修改java.env，修改zoo.cfg
4、配置HBase
创建keytab，修改hbase-env.sh/hbase-site.xml等等
hbase-site.xml中主要是添加下述配置：
hbase.security.authentication
kerberos
添加了如上配置，便使能了hbase的权限控制，此时只有经过了认证的服务器，才能够成功向master申报，所以如果host没有配置kerberos时，贸然添加上述配置可能会导致regionserver进程难以启动；
总结：
1、kerberos提供了机器级别的安全认证，但调研及尝试安装下来之后，觉得首先kerberos的安装流程复杂，如果是建设新集群，可以考虑使用kerberos，但当前集群已经存在上百个业务在时时跑，复杂的安装流程势必会造成业务中断，不是业务方所能接受的；
2、kerberos对应用访问集群的性能有一定影响，加了kerberos认证后，client端再想访问集群，需要先两次访问KDC，第一次访问向KDC证明我是我自己，第二次访问时生成services端和client端之间的session key用于service端对client的身份鉴别，一次用户请求的访问路径变长，必然有性能损耗；
3、使用kerberos，也添加了外部需要维护的依赖，包括KDC&数据库DB等等
（二）Authorization
a、使用方式：
使能hbase的ACL控制比较简单，只需要在集群的各个节点hbase-site.xml添加如下配置即可
hbase.security.authorization
true
hbase.superuser
默认是hbase的安装用户
hbase.coprocessor.master.classes
org.apache.hadoop.hbase.security.access.AccessController
hbase.coprocessor.region.class
org.apache.hadoop.hbase.security.token.TokenProvider,org.apache.hadoop.hbase.security.access.AccessController
其中，hbase.superuser是超级用户，可以不配置，不配置时默认是hbase的安装用户，超级用户用于给其它用户添加或者收回相应权限；
AccessController类是hbase权限控制的主入口类，关于hbase权限控制的机理在下文中有简述；
b、Authorization中可认证的权限都包括了哪些：
R——范围内可读；
W——范围内可写；
X——可以执行授权范围内埋设的coprocessor；
C——范围内可执行creat操作，如scope指定为namespace，则C是指ns之内可以创建表，如scope指定为table，则C是指可对table执行create snapshot操作；
A——范围内可以执行admin操作，如果你的scope是namespace，那么admin操作是指balance、assign、move、merge等，如果你的scope是table，那么admin操作是指alter操作，即修改表属性；
需要注意的是：
1、表的disable权限由’C’认证控制
2、表数据的删除权限由’W’认证控制
c、上面的“scope”都包含了哪些维度：
hbase包含了如下几种可定义的scope维度：
superuser——超级管理员，可执行针对集群的任意操作，一般为集群的安装者，superuser也可以由用户添加，即hbase.superuser配置；
global——全局scope，可操作所有tables；
namespace——可操作指定namespace内的scope，我们的namespace只有一个，就是default；
table——可操作指定的table；
ColumnFamily——可操作指定的columnFamily；
cell——具体到列元的scope指定；
e、hbase权限控制的实现原理：
几个实现要点：
AccessContoller实现了CoprocessorService接口，并继承了Observer类，这说明AccessContoller是一个observer endpoint，即hbase里的coprocessor插件。
AccessContoller作为observer覆写了postStartMaster方法，用于在master启动完成之后调createACLTable来创建acl table，acl table是hbase的system tables之一，用于持久化保存所有的权限信息。acl table和用户表一样都分region存储在regionserver上。
RegionServer启动之后，会逐一open各regionserver上的regions，AccessController同样覆写了postOpen函数，postOpen在region被open之后触发，如果打开的是属于acl table的region，AccessController会遍历该region中的所有内容，load到AccessController维护的一个map中，与此同时，这些数据同时被序列化之后写到zk上，关键代码如下：
void initialize(RegionCoprocessorEnvironment e) throws IOException {
final Region region = e.getRegion();
Configuration conf = e.getConfiguration();
Map> tables = AccessControlLists.loadAll(region);
for (Map.Entry> t : tables.entrySet()) {
byte[] entry = t.getKey();
ListMultimap perms = t.getValue();
byte[] serialized = AccessControlLists.writePermissionAsBytes(perms, conf);
this.authManager.getZKPermissionWatcher().writeToZookeeper(entry,serialized);
}
initialized=true;
} acl region被加载到AccessContoller的map之后，一个AccessContoller才真正初始化完成。
AccessContoller还实现了coprocessorService接口，这是一个可序列化的service接口，coprocessorService在coprocessor被加载到host的时候实例化，具体实现在coprocessorHost的loadInstance中：
public E loadInstance(Class implClass, int priority, Configuration conf)
throws IOException {
// create the instance
Coprocessor impl;
Object o = null;
try {
o = implClass.newInstance();
impl = (Coprocessor)o;
} catch (InstantiationException e) {
throw new IOException(e);
} catch (IllegalAccessException e) {
throw new IOException(e);
}
// create the environment
E env = createEnvironment(implClass, impl, priority, loadSequence.incrementAndGet(), conf);
if (env instanceof Environment) {
((Environment)env).startup();
}
coprocessorNames.add(implClass.getName());
return env;
} createEnvironment中会将各个coprocessorService实例register到masterService上，而在AccessControlService反射出来的类所需要实现的接口，就是shell中hbase权限相关的四个命令：
grant、revoke、getUserPermissions、checkPermissions
其中grant用于授权操作，revoke用于收回用户权限，其余两个是查询操作，以grant接口为例，其实现代码如下所示：
public void grant(RpcController controller,
AccessControlProtos.GrantRequest request,
RpcCallback done) {
final UserPermission perm = ProtobufUtil.toUserPermission(request.getUserPermission());
AccessControlProtos.GrantResponse response = null;
try {
// verify it's only running at .acl.
if (aclRegion) {
if (!initialized) {
throw new CoprocessorException("AccessController not yet initialized");
}
//用户鉴权
switch(request.getUserPermission().getPermission().getType()) {
case Global :
case Table :
requirePermission("grant", perm.getTableName(), perm.getFamily(),
perm.getQualifier(), Action.ADMIN);
break;
case Namespace :
requireGlobalPermission("grant", Action.ADMIN, perm.getNamespace());
break;
}
//执行权限添加，向acl table新写入一条记录
User.runAsLoginUser(new PrivilegedExceptionAction() {
@Override
public Void run() throws Exception {
AccessControlLists.addUserPermission(regionEnv.getConfiguration(), perm);
return null;
}
});
} else {
throw new CoprocessorException(AccessController.class, "This method "
+ "can only execute at " + AccessControlLists.ACL_TABLE_NAME + " table.");
}
response = AccessControlProtos.GrantResponse.getDefaultInstance();
} catch (IOException ioe) {
ResponseConverter.setControllerException(controller, ioe);
}
//执行回调操作
done.run(response);
}
在AccessController保存权限信息的map中，维护了一个ZKPermissionWatcher类型的变量，该变量继承了zookeeperListener，可见该变量可用于监听zk节点上的变化，前面说过acl table的信息会序列化到zk上，如果用户修改acl table的内容，这些修改会同步到zk到，反映为zk节点的变化，zkPermissionWatcher监听zk节点的变化，同步修改AccessController中map的内容，实现了内存、zk与acl table三者之间数据的一致。
下面讲讲zookeeperListener的初始化方式，AccessController在start的时候，会通过env获取该服务上的zookeeperWatcher，并将zkwatcher和config一起构造TableAuthManager，在TableAuthManager的构造函数中，使用上述两个参数和TableAuthManager自身构造成员变量ZKPermissionWatcher，并将之start，start函数的关键代码如下：
public void start() throws KeeperException {
try {
watcher.registerListener(this);
if (ZKUtil.watchAndCheckExists(watcher, aclZNode)) {
List existing =
ZKUtil.getchildDataAndWatchForNewChildren(watcher, aclZNode);
if (existing != null) {
refreshNodes(existing);
}
}
} finally {
initialize.countDown();
}
} 总而言之，hbase acl权限的控制是通过hbase自身系统表acl table做持久化，具体发挥作用则是由AccessControler加载进内存，以便于权限的查询结果能够直接从内存返回，减少权限认证对数据访问性能的影响，而保证table和内存内容一致性则是由zookeeper来实现。
f、hbase自带权限的几个注意点（坑点）
1）权限内容通过zk同步，可能会导致部分节点不能准确同步到最新的权限内容，造成不一致，hbase2.0中的procedure V2解决了上述问题，proceduer V2引入了两阶段提交的框架，只有所有节点的更新都成功之后，才确认此次更新成功，否则回滚；
2）生效不平滑，acl生效之后除superuser之外的用户默认不具有任何权限，而新用户授权操作grant只有在acl生效之后才能使用，这造成的问题是，如果在时时有用户读写数据的hbase集群上生效acl，会造成集群在一段时间对所有用户停服。
2、apache ranger的权限控制
a）apache ranger的基本原理：
Apache Ranger也是以coprocessor的形式集成到HBase中，由Ranger Admin管理访问策略，具体的权限策略存储在外部DB中，Ranger插件定期轮询Admin以更新策略到本地，并根据策略信息进行用户权限的判定，其中同样包含一个super用户，可以管理所有策略。插件的ranger web和Ranger Plugin，与Admin之间的通信是基于Http的Restful来实现。
关于Ranger插件的具体机制原理和初始化流程，本文不再详述，只列出它与HBase自带权限控制策略的比较：
1、ranger将权限策略存储于外部DB，由第三方角色Ranger Admin管理，HBase则存储于自身的系统表acl table中，由superuser（HBase的安装用户）管理；
2、新权限的更新方面，ranger是由编译到HBase上的插件Plugin，定期向admin发送restfule请求，以拉取最新的policy，而HBase的自身实现是依靠zk做集群各节点权限信息同步一致；
3、权限的执行，两者相同，都是依赖coprocessor在client端行为的前后埋hook，用户权限的查询都是从内存中获得，ranger是从Plugin中维护的内存，而hbase自带的是从AccessController中维护的内存；
4、权限管理的粒度，两者相似，都可以管理到namespace/table/column family/cell这四个粒度，具体的权限内容，同样包括了get&scan，写，create table等等；
5、关于grant、revoke等操作，ranger掩盖了hbase中的实现，hbase中的不再生效，想要操作从ranger admin入口进行操作；
总结：
对于apache ranger，一需要外部部署DB，solr等外部系统，增加了第三方系统就增加了维护的难度，比如ranger的DB挂掉，那么同样会影响到hbase，造成hbase的数据无法访问；
二、是DB容易成为该系统的单点，因为所有的策略更新都要访问该DB；
三、权限的生效周期不如hbase自带策略及时；