Hadoop安全机制介绍

1．背景

1.1 共享Hadoop集群

当前大一点的公司都采用了共享Hadoop集群的模式，这种模式能够减少维护成本，且避免数据过分冗余，增长硬件成本。共享Hadoop是指：（1）管理员把研发人员分红若干个队列，每一个队列分配必定量的资源，每一个用户或者用户组只能使用某个队列中得资源；（2）HDFS上存有各类数据，有公用的，有机密的，不一样的用户能够访问不一样的数据。

共享集群相似于云计算或者云存储，面临的一个最大问题是安全。

1.2 几个概念

安全认证：确保某个用户是本身声称的那个用户。

安全受权：确保某个用户只能作他容许的那些操做

User：Hadoop用户，能够提交做业，查看本身做业状态，查看HDFS上的文件

Service：Hadoop中的服务组件，包括：namenode，jobtracker，tasktracker，datanode

1.3  Hadoop安全机制现状

Hadoop 一直缺少安全机制，主要表如今如下几个方面：

(1) User to Service

[1] Namenode或者jobtracker缺少安全认证机制

Client的用户名和用户组名由本身指定。

若是你不指定用户名和用户组，Hadoop会调用linux命令“whoami”获取当前linux用户名和用户组，并添加到做业的user.name和group.name两个属性中，这样，做业被提交到JobTracker后，JobTracker直接读取这两个属性（不通过验证），将该做业提交到对应队列（用户名/用户组与队列的对应关系由专门一个配置文件配置，详细可参考fair scheduler或者capacity scheduler相关文档）中。若是你能够控制你提交做业的那台client机器，你能够以任何身份提交做业，进而偷偷使用本来属于别人的资源。

好比：你在程序中使用如下代码：

conf.set(“user.name”, root);

conf.ser(“group.name”, root);

即可以以root身份提交做业。

[2] DataNode缺少安全受权机制

用户只要知道某个block的blockID，即可以绕过namenode直接从datanode上读取该block；用户能够向任意datanode上写block。

[3] JobTracker缺少安全受权机制

用户能够修改或者杀掉任意其余用户的做业；用户能够修改JobTracker的持久化状态。

(2) Service to service安全认证

Datanode与TaskTracker缺少安全受权机制，这使得用户能够随意启动假的datanode和tasktracker，如：

你能够直接到已经启动的某个TaskTracker上启动另一个tasktracker：

./hadoop-daemon.sh start datanode

（3）磁盘或者通讯链接没有通过加密

2. Hadoop安全机制

为了加强Hadoop的安全机制， 从2009年起， Apache专门抽出一个团队，为Hadoop增长安全认证和受权机制，至今为止，已经可用。

Apache Hadoop 1.0.0版本和Cloudera CDH3以后的版本添加了安全机制，若是你将Hadoop升级到这两个版本，可能会致使Hadoop的一些应用不可用。

Hadoop提供了两种安全机制：Simple和Kerberos。Simple机制（默认状况，Hadoop采用该机制）采用了SAAS协议。 也就是说，用户提交做业时，你说你是XXX（在JobConf的user.name中说明），则在JobTracker端要进行核实，包括两部分核实，一是你究竟是不是这我的，即经过检查执行当前代码的人与user.name中的用户是否一致；而后检查ACL（Access Control List）配置文件（由管理员配置），看你是否有提交做业的权限。一旦你经过验证，会获取HDFS或者mapreduce授予的delegation token（访问不一样模块由不一样的delegation token），以后的任何操做，好比访问文件，均要检查该token是否存在，且使用者跟以前注册使用该token的人是否一致。

注意：下面绝大多数安全机制都是基于Kerberos实现的。

3. RPC安全机制

在Hadoop RP中添加了权限认证受权机制。当用户调用RPC时，用户的login name会经过RPC头部传递给RPC，以后RPC使用Simple Authentication and Security Layer（SASL）肯定一个权限协议（支持Kerberos和DIGEST-MD5两种），完成RPC受权。

具体参考：https://issues.apache.org/jira/browse/HADOOP-6419

4．HDFS安全机制

Client获取namenode初始访问认证（使用kerberos）后，会获取一个delegation token，这个token能够做为接下来访问HDFS或者提交做业的凭证。

一样，为了读取某个文件，client首先要与namenode交互，获取对应block的的block access token，而后到相应的datanode上读取各个block，而datanode在初始启动向namenode注册时，已经提早获取了这些token，当client要从TaskTracker上读取block时，首先验证token，经过后才容许读取。

5. MapReduce安全机制

【Job Submission】

全部关于做业的提交或者做业运行状态的追踪均是采用带有Kerberos认证的RPC实现的。受权用户提交做业时，JobTracker会为之生成一个delegation token，该token将被做为job的一部分存储到HDFS上并经过RPC分发给各个TaskTracker，一旦job运行结束，该token失效。

【Task】

用户提交做业的每一个task均是以用户身份启动的，这样，一个用户的task便不能够向TaskTracker或者其余用户的task发送操做系统信号，最其余用户形成干扰。这要求为每一个用户在全部TaskTracker上建一个帐号。

【shuffle】

当一个map task运行结束时，它要将计算结果告诉管理它的TaskTracker，以后每一个reduce task会经过HTTP向该TaskTracker请求本身要处理的那块数据，Hadoop应该确保其余用户不能够获取map task的中间结果，其作法是：reduce task对“请求URL”和“当前时间”计算HMAC-SHA1值，并将该值做为请求的一部分发动给TaskTracker，TaskTracker收到后会验证该值的正确性。

6．WebUI安全机制

这一块须要针对每一个用户单独配置。

7．高层服务的安全机制

你可能会在Hadoop之上使用Oozie，HBase，Cassandra等开源软件，为此，你须要在这几个软件的配置文件和Hadoop配置文件中添加权限，具体方法参考：https://ccp.cloudera.com/display/CDHDOC/CDH3+Security+Guide

8．总结

下面对Hadoop在安全方面的改动进行汇总：

（1） HDFS

命令行不变，WEB UI添加了权限管理

（2） MapReduce添加了ACL

包括：

管理员可在配置文件中配置容许访问的user和group列表

用户提交做业时，可知道哪些用户或者用户组能够查看做业状态，使用参数-D mapreduce.job.acl-view-job

用户提交做业时，可知道哪些用户或者用户组能够修改或者杀掉job，使用参数：-D mapreduce.job.acl-modify-job

（3）MapReduce系统目录（即：mapred.system.dir，用户在客户端提交做业时，JobClient会将做业的job.jar，job.xml和job.split等信息拷贝到该目录下）访问权限改成700

（4）全部task以做业拥有者身份运行，而不是启动TaskTracker的那个角色，这

使用了setuid程序（C语言实现）运行task。 【注】若是你以hadoop用启动了Hadoop集群，则TaskTracker上全部task均以hadoop用户身份运行，这很容易使task之间相互干扰，而加了安全机制后，全部task以提交用户的身份运行，如：用户user1提交了做业，则它的全部task均以user1身份运行。

（5）Task对应的临时目录访问权限改成700

（6）DistributedCache是安全的

DistribuedCache分别两种，一种是shared，能够被全部做业共享，而private的只能被该用户的做业共享。

9．有用的资料

（1）Map and Reduce tasks should run as the user who submitted the job

（2）Security features for Map/Reduce

（包含一个pdf文件，里面有关于Hadoop安全机制的详细说明）

（3）Hadoop Security DesignJust Add Kerberos? Really?

（4）hadoop-security-preview

（5）hadoop-security indetails in hadoop summit 2010

（6） 安装Hadoop Kerbores方法