安全性
早期的Hadoop版本假定HDFS和MapReduce集群运行在安全的环境之中，由一组 相互合作的用户所使用，因而其访问控制措施的目标防止偶然的数据丢失，而非阻 止非授权的数据访问。例如，HDFS中的文件许可模块会阻止用户由于程序漏洞而 毁坏整个文件系统，也会阻止运行不小心输入的hadoop fs -rmr /指令。然而， 它无法阻止一个恶意用户假冒root标识
从安全角度分析，Hadoop缺乏一个安全的认证机制，以确保试图在集群上执行操 作的用户恰是所声称的安全用户。但是，Hadoop的文件许可模块只提供一种简单 的认证机制，以决定各个用户对特定文件的访问权限。例如，某个文件的读权限仅 开放给某用户一组，从而阻止其他用户组成员读取该文件。然而，这种认证机制仍 然远远不够，只要恶意用户能够通过网络访问集群，就有可能伪造合法身份来攻击 系统。
包含个人身份信息的数据（例如终端用户的全名或IP地址）非常敏感。一般情况 下，需要严格限制组织内部的能够访问这类信息的员工数。相比之下，敏感性不强 (或匿名)的数据则可以开放给更多用户。如果把同一集群上的数据划分不同的安全 级别，在管理上会方便很多，特别是这意味着低安全级别的数据能够被广泛共享。 然而，为了迎合数据保护的常规需求，共享集群的安全认证是不可或缺的。
Yahoo!公司在2009年就遇到了这个难题，因此他们组织了一个工程师团队来实 现Hadoop的安全认证。这个团队提出的方案用kerberos(—个成熟的开源网络认 证协议)实现用户认证，Hadcop不直接管理用户隐私，而Kerberos也不关心用户 的授权细节。换句话说，kerberos的职责在于鉴定登录帐号是否是他所声称的用 户，Hadoop则决定这个用户到底拥有多少权限。Kerberos技术比较复杂，因此 这里只介绍在HadoiDp系统中的用法。若想了解更多背景，可以参阅Jason Garman 所著的 “Kerberos: The Definitive Guide" (O'Reilly, 2003),网址为 http://oreilly.com/catalog/97805960040331。
Apache Hadoop在0.20版本之后开始添加Kerberos认证技术。然而，直到0.21 版本，这项工作仍未完全结束。因此，在0.22版本之前，这项特性的有效性和 稳定性均不成熟。除此之外，Yahoo! Distribution of Hadoop的0.20.S版本和Cloudera的第一个稳定的CDH3发布中也有这项安全支持。
Kerberos 和 Hadoop
从宏观角度来看，使用Kerberos时，一个客户端需要经过三个步骤来获取服务。 在各个步骤，客户端需要和一个服务器交换报文。
1.认证。客户端向认证服务器发送一条报文，并获取一个含时间戳的票据授予票 据(Ticket-Granting Server, TGT)。
2.授权。客户端使用TGT向票据授予服务器(Ticket-Granting Server, TGS)请求 一个服务票据。
3.服务请求。客户端向服务器出示服务票据，以证实自己的合法性。该服务器提 供客户端所需服务，在Hadoop应用中，服务器可以是namenode或 jobtracker。
同时，认证服务器和票据授予服务器构成了密钥分配中心（Key Distribution Center, KDC)。整个过程如图9-2所示。
图9-2.Kerberos票据交换协议的三个步骤
授权和服务请求步骤并非用户级别的行为：客户端系统会代替用户来执行这些步 骤。但是认证步骤通常需要由用户调用kinit命令来执行，该过程会提示用户输 入密码。需要指出的是，这并不意味着每次运行一个作业或访问HDFS的时候都 会强迫用户键入密码，因为用户所申请到的TGT具备一定的有效期，可以重用。 在默认情况下，TGT的有效期是10个小时，甚至还可以更新至一周。更通用的做 法是采用自动认证：即在登录操作系统的时候自动执行认证操作，从而只需单次登录:(single sign-on)到Hadoop。
如果用户不期望被提示输入密码(例如，运行一个无人值守的MapReduce作业），则 可以使用ktutil命令创建一个Kerberos的keytab文件，该文件保存了用户密码 并且可以通过-t选项应用于kinit命令。
委托令牌
在诸如HDFS或MapReduce的分布式系统中，客户端和服务器之间频繁交互，且 每次交互均需认证。例如，一个HDFS读操作不仅会与namenode多次交互、还会 与一个或多个datanode交互。如果在一个髙负载集群上采用三步骤Kerberos票据 交换协议来认证每次交互，则会对KDC造成很大压力。因此，Hadoop使用委托令 牌来支持后续认证访问，避免了多次访问KDC。委托令牌的创建和使用过程均由 Hadoop代表用户透明地进行，因而用户在执行kinit命令登录之后就不需要做任 何操作了。当然，了解委托令牌的基本用法仍然是有必要的。
委托令牌由服务器创建(在这里是指namenode),可以视为客户端和服务器之间共 享的一个密文。当客户端首次通过RPC访问namenode时，客户端并没有委托令 牌，因而需要利用Kerberos进行认证。之后，客户端从namenode取得一个委托令 牌。在后续&?匚调用中，客户端只需出示委托令牌，namenode就能验证委托令牌 的真伪（因为该令牌是由namenode使用密钥创建的），并因此向服务器认证客户端 的身份。
客户端需要使用一种特殊类型的委托令牌来执行HDFS块操作，称为“块访问令 牌” (block access token)。客户端向namenode发出元数据请求，namenode创建块 访问令牌并发送回客户端。客户端使用块访问令牌向datanode证实自己的身份。 由于namenode会和datanode分享它创建块访问令牌时用的密钥(通过心跳消息传 送），datanode也能够验证这些块访问令牌。这样的话，仅当客户端已经从 namenode获取了针对某一个HDFS块的块访问令牌，才可以访问该块。相比之 下，在不安全的Hadoop系统中，客户端只知道块ID就能够访问一个块。可以通过将dfs.block.access.token.enable的值设置为true来启用块访问令牌特性。
在MapReduce中，jobtracker共享HDFS中的作业资源和元数据(例如JAR文件， 输入分片，配置文件)。用户代码运行在tasktracker上，并可以访问HDFS上的文 件。在 作业运行过程中，jobtracker和tasktracker使用委托令牌访问HDFS。作业结束 时，委托令牌失效。
默认的HDFS实例会自动获得委托令牌。但是若一个作业试图访问其他HDFS集 群，则用户必须将mapreduce.job.hdfs-servers作业属性设置为一个由逗号隔 开的HDFS URI幻列表，才能够获取相应的委托令牌。
其他安全性改进
HDFS和MapReduce已经全面强化了安全措施，以阻止用户在未授权的情况下访 问资源。重要的变化列举如下。
任务可以由提交作业的用户以操作系统帐号启动运行，而不一定要由运行 tasktracker的用户启动。因此，可以借助操作系统来隔离正在运行的任务，使 他们之间无法相互传送指令(例如，终止其他用户的任务），这样的话，诸如任 务数据等本地信息的隐私即可以通过本地文件系统的安全性而得到保护。
任务由提交作业的用户启动运行时，分布式缓存是安全的：对于所有用户均可读的文件被放到共享缓存中(默认的非 安全方式)，其他文件放在一个私有缓存之中，仅由拥有者读取。
用户只能查看和修改他们自己的作业，无法操控他人的作业。为了启动该特 性，需要将mapred.acls.enabled属性项设为true。另外， mapreduce.job.acl-view-job 和 mapreduce.job .acl-modify-job 属性项分别对应一个逗号分隔的用户列表，描述能够査看或修改指定作业的所有 用户。
shuffle是安全的，可以阻止恶意用户请求获取其他用户的map输出。
可以阻止恶意的辅助namenode、datanoe或tasktracker加入集群，从而破坏集 群中的数据。这可以通过要求master节点对试图与之连接的守护进程进行认 证来实现。
为了启用该特性，需要使用先前由ktutil命令创建的keytab文件。以 datanode 为例，首先，把 dfs.datanode.keytab.file 属性项设置为 keytab 文件名称：其次，把dfs.datanode.kerberos.principal属性设置为 datanode要用的用户名称•最后，把hadoop-policy.xml文件中 security.datanode.protocol.acl 属性设置为 datanode 的用户名称，以设 置 DataNodeProtocol 的 ACL。DatanodeProtocol 是 datanode 用于和 namenode通信的协议类。
datanode最好运行在特权端口（端口号小于1024),使客户端确信它是安全启 动的。任务仅仅和其父tasktracker通信，从而阻止攻击者经由其他用户的作业获取 MapReduce 数据。
到目前为止，Hadoop还未考虑数据加密问题^不管是RPC还是块传输，数据均未 被加密。此外，HDFS块也没有以加密方式被存储。这些特性预计会加到未来发布 中去。实际上，可以将当前Hadoop版本与特定应用程序相结合，以提供加密特 性。（例如，写一个加密CompressionCodec类）。
