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机器，你可以以任何身份提交作业，进而偷偷使用原本属于别人的资源。

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

便可以以root身份提交作业。

[2] DataNode缺乏安全授权机制

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

[3] JobTracker缺乏安全授权机制

用户可以修改或者杀掉任意其他用户的作业；用户可以修改JobTracker的持久化状态。

(2) Service to service安全认证

Datanode与TaskTracker缺乏安全授权机制，这使得用户可以随意启动假的datanode和tasktracker，如：

你可以直接到已经启动的某个TaskTracker上启动另外一个tasktracker：

（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安全机制

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

用户提交作业的每个task均是以用户身份启动的，这样，一个用户的task便不可以向TaskTracker或者其他用户的task发送操作系统信号，最其他用户造成干扰。这要求为每个用户在所有TaskTracker上建一个账号。

当一个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

原创文章，转载请注明： 转载自董的博客

本文链接地址:http://dongxicheng.org/mapreduce/hadoop-security/