转自：http://www.spnguru.com/2011/07/678/
构建和运维HBase集群是一个非常有挑战性的工作。HBase凭借其在海量数据的良好的扩展性和高效的读写能力，受到越来越多公司的重视。
在公司里，HBase越来越受欢迎。希望通过HBase读写数据的产品越来越多，在兴奋之余，头疼的问题也来了。毕竟，作为线上的产品，我们不希望过多人随意的访问，会照成很多潜在的风险，比如误删，误操作。但是，如果所有事情都有管理员处理，沟通的代价就会很高，而且管理员不得不处理一些Application相关的工作，导致管理低效。访问控制，就成为了一个很重要的需求。
此外，现在部署在云计算公有云的HBase集群也在日益增多，如果没有访问控制，存储其中的数据可以随意删改，对企业而言，也是无法接受的。那么HBase 的访问控制就成为了一个迫切紧急的任务。
Apache Hadoop 在0.20版本之后开始添加Kerberos认证技术。然而，直到0.21版本，这项工作仍未结束。因此，在0.22版本之前，这项特性的有效性和稳定性均不成熟。此外，Yahoo！ Distribution of Hadoop 的0.20.S版本和Cloudera的第一个稳定的CDH3发布中也会加入这项安全支持。
HBase的访问控制是也是基于Kerberos的，现在，在我们的产品环境中，已经集成了Hadoop和HBase的访问控制功能。在后面的文章里，我将详细阐述HBase访问控制的具体功能和实现机制。供大家参考。
Secure HBase的特征。
1. 和Yahoo！Distribution of Hadoop 一样，基于Kerberos。在我们的环境中，我们同时部署了Secure Hadoop和Secure HBase， 关于Secure Hadoop，可以参考（Hadoop-4487）
2. 实现Coprocessor Framework, 允许HBase 管理员在Regionserver中载入定制的代码，关于Coprocessor，请参考（HBase-2001）
3. 实现了一个AccessController的Coprocessor，在代码中加入了Access Control。请参考（HBase-3025）
4. 支持基于表和column family的访问控制，不支持row级别。
认证机制
认证机制利用了Java的JAAS。 当HBase接受到透过RPC过来的请求时，将调用JAAS的doAs函数执行这个命令。具体的代码变动，可以看下面的代码比较。
- diff --git a/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java b/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java
- index 40473e3..2dec6b5 100644
- --- a/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java
- +++ b/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java
- @@ -58,6 +58,7 @@
- import java.util.concurrent.ConcurrentHashMap;
- import java.util.concurrent.ExecutorService;
- import java.util.concurrent.Executors;
- import java.util.concurrent.LinkedBlockingQueue;
- +import java.security.PrivilegedExceptionAction;
- import org.apache.commons.logging.Log;
- import org.apache.commons.logging.LogFactory;
- @@ -1060,7 +1061,7 @@ public abstract class HBaseServer implements RpcServer {
- ByteArrayOutputStream buf = new ByteArrayOutputStream(buffersize);
- while (running) {
- try {
- - Call call = myCallQueue.take(); // pop the queue; maybe blocked here
- + final Call call = myCallQueue.take(); // pop the queue; maybe blocked here
- if (LOG.isDebugEnabled())
- LOG.debug(getName() + ": has #" + call.id + " from " +
- @@ -1073,7 +1074,32 @@ public abstract class HBaseServer implements RpcServer {
- CurCall.set(call);
- // TODO: simple auth -- store user in context
- try {
- - value = call(call.connection.protocol, call.param, call.timestamp); // make the call
- + Object obj = (Writable)call.connection.ticket.doAs(new PrivilegedExceptionAction<Object>() {
- + public Object run() throws IOException, InterruptedException {
- + return call(call.connection.protocol, call.param,
- + call.timestamp);
- + }
- + });
- +
- + if (obj instanceof Writable) {
- + value = (Writable)obj;
- + }
- + else {
- + // doAs() return value could not be converted to Writable:
- + // probably should throw an exception here in that case.
- + }
- } catch (Throwable e) {
- LOG.debug(getName()+", call "+call+": error: " + e, e);
- errorClass = e.getClass().getName();
权限和授权
HBase的权限定义比较简单。比如我们不会区分是insert还是update，而统一是Put。
HBase的权限可以分为基于行和基于schema。基于行包括对表的读写。基于schema的包括了增加一列或者增加一个family，删除表之类的操作。前者是在Regionserver中运行，但是后者是在master中执行。在master中运行的不会在Coprocessor Framework中运行，但是我们上面的代码将运行在master和Regionserver中，所以不论用户是执行基于行的操作还是基于schema的操作，都可以实现访问控制。
表的所属权
所属权定义在表的TableDescriptor，对应于 .META. 中的regioninfo：owner这一栏。表的所有者有权利读写表和删除表。任何人有权利读 –ROOT— 和 .META. , 但只有HBase 管理员修改表的所属权属性。比如，如果有一个客户端希望能读表的信息，但是你担心他会误删表的数据，就可以建立一个对某个表只读权限的用户。
Coprocessor
Coprocessor已经融合到了HBase 0.90 的版本中。如果enable了Coprocessor，RegionServer会从配置文件hbase-site.xml 中读取Coprocessor的配置。下面是Access Control coprocessor的配置片段。
<property>
<name>hbase.coprocessor.default.classes</name>
<value>org.apache.hadoop.hbase.security.rbac.AccessController</value>
</property>
Coprocessor的接口定义了一组pre- 和post- 的函数，每个对应于客户端的一个request。
比如，客户端的函数Get（），在Coprocessor中就会定义preGet（）和postGet（）， preX（）和postX（）会抛出CoprocessorException。可以定义任意数量的Coprocessor。其实这个和动态代理类似。如图，定义了三个preGet（）和三个postGet（），如果遇到异常，异常将直接抛给用户终止后面的进行。
利用pre-X方法，我们可以实现访问控制。比如，如果一个客户端发送Put（T，Row）到一个Regionserver，Regionserver会首先调用用于认证的Coprocessor函数prePut检测该用户是否对该表有写权限。如果有，则写入，否则，抛出AccessDeniedException异常。
上图是preX和permission的对应关系。
吃外，我们用preX做permission 检测的同时，也使用了两个postX方法——postOpen（）和postPut（） 来存储Permission信息。
如何存储Permissions
表Table1的Permission会存储在三个地方。
1. Table1的第一个region在 .META.表所在的行
2. Zookeeper中/hbase/acl/table1节点
3. 所有管理table1的RegionServer在内存中的权限镜像。
.META.
我们在.META.上面加了一个colum family，acl：。对于任意一个表T, Permission信息存储在该表在.META.的第一行，存储在acl：U列中（U表示username），值可以是R,W,RW。这是Permission信息存储的原始位置，Zookeeper和regionServer的信息都是从这里拷贝的。当Secure HBase第一次启动的时候，.META. regions 首先被load到RegionServer，之后拷贝到Zookeeper和Regionserver的镜像。当权限被管理员改变，也是先修改.META. 然后到Regionserver 的mirrors。
Zookeeper
Zookeeper在.META和Regionserver镜像中起到一个桥梁的作用。在Zookeeper中，Permission 信息会存放在/hbase/acl/T， 所有含有表T region的Regionserver都会设置watch来监视Permission信息的改变。
Regionserver的内存镜像
每一个Regionserver都会为他服务的regions维护一个内存权限镜像。镜像的内容来自于拷贝相应Zookeeper节点的Permission信息得到。Zookeeper和Regionserver的镜像之间的一致性是靠Zookeeper Watches保证的。
Zookeeper起的作用
当一个Regionserver打开一个.META. region时，AccessController:postOpen() 扫描出表在.META.中所有的第一行，建立Zookeeper 节点/hbase/acl/T，acl：columns的每行都被拷贝到Zookeeper的节点上。形成一个user=>Permission的映射表。
维护一致性： 从.META.到Zookeeper
当管理员修改了Permission信息时，实际上是对.META.的第一行出发了put操作。这会触发Coprocessor的PostPut 方法。在PostPut里，我们将修改的权限保存到对应的/hbase/acl/T节点中。
维护一致性： 从Zookeeper到Regionserver 权限镜像
下图表示两个Regionserver，每一个都有一个ZKPermissionWatcher，实现了nodeCreated()和nodeChanged()方法。对于每一个watcher 方法，改变对应的Zookeeper节点都会触发Permission镜像的刷新。
注意，Regionserver仅仅使用本地的权限镜像，而不是使用Zookeeper或者.META.来认证客户端的请求。这是处于性能的考虑。但是，如何确保每次都执行正确的认证信息？这要求Regionserver的镜像和.META.中的Permission完全一致。因为表T它的第一个region对应的.META.的那个region被打开之后才能被打开，这就保证了regionserver总是先于任何客户端之前导入Permission信息。
总结
1. META中的acl： 这个family用于存储Permission信息。Zookeeper能够自动快速地将权限的改动更新到本地的权限缓存中。
2. 一个用户的操作既不需要查询META也不需要查询Zookeeper。最新的信息能从本地缓存中获得。
3. 修改权限不需要disable表，对表权限的更新将立即并自动地通过Zookeeper从META表更新到regionserver
实例分析
现在，我们来看一个权限处理的例子
S代表处理的Regionserver, 而U代表用户。
在第三步，doAs()将HBase的系统用户转化为一个普通的U用户，类似unix的sudo su,
第五步，如果认证失败，就会返回AccessDeniedException。
1138
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
