标签：
当前大一点的公司都采用了共享Hadoop集群的模式，这种模式可以减小维护成本，且避免数据过度冗余，增加硬件成本。共享Hadoop是指：（1）管理员把研发人员分成若干个队列，每个队列分配一定量的资源，每个用户或者用户组只能使用某个队列中得资源；（2）HDFS上存有各种数据，有公用的，有机密的，不同的用户可以访问不同的数据。
共享集群类似于云计算或者云存储，面临的一个最大问题是安全。
安全认证：确保某个用户是自己声称的那个用户。
安全授权：确保某个用户只能做他允许的那些操作
User：Hadoop用户，可以提交作业，查看自己作业状态，查看HDFS上的文件
Service：Hadoop中的服务组件，包括：namenode，jobtracker，tasktracker，datanode
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）磁盘或者通信连接没有经过加密
为了增强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实现的。
在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
Client获取namenode初始访问认证（使用kerberos）后，会获取一个delegation token，这个token可以作为接下来访问HDFS或者提交作业的凭证。
同样，为了读取某个文件，client首先要与namenode交互，获取对应block的的block access token，然后到相应的datanode上读取各个block，而datanode在初始启动向namenode注册时，已经提前获取了这些token，当client要从TaskTracker上读取block时，首先验证token，通过后才允许读取。
【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收到后会验证该值的正确性。
这一块需要针对每个用户单独配置。
你可能会在Hadoop之上使用Oozie，HBase，Cassandra等开源软件，为此，你需要在这几个软件的配置文件和Hadoop配置文件中添加权限，具体方法参考：https://ccp.cloudera.com/display/CDHDOC/CDH3+Security+Guide
下面对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的只能被该用户的作业共享。
（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?
（5）hadoop-security indetails in hadoop summit 2010
标签：
原文地址：http://my.oschina.net/u/2377453/blog/466443
