简介
Apache基金会开源项目，分布式计算基础架构Hadoop收到越来越多的重视。基于Hadoo和HDFS的分布式计算架构的使用越来越广泛。Hadoop 首先作为 Lucene 的子项目 Nutch 的一部分正式引入。它受到最先由Google开发的MapReduce和GFS的启发。
但是Hadoop在设计实现的时候没有考虑过安全性的问题。因此，Hadoop中存在着很多安全性漏洞，这使得分布式计算平台安全收到了极大的威胁。其中最大的问题就是，HDFS中存储的数据是没有安全限制的，意即，只要能提交一个任务（job），就能通过该任务访问HDFS上所有的数据。
Kerberos是由MIT设计并开发的一套三方安全认证协议，并已写入RFC标准。目前最新的标准时Krb5。Kerberos通过第三方可信机构KDC对需要通信的双方进行认证。由于其详尽的设计，使其可以应对大多数攻击方法。而不由KDC存储会话秘钥和会话过程不由KDC参与的特性，使其具有非常高的性能。
Java StandardEdition (J2SE)使用了kerberos v5实现了单点登录，增强了Java安全架构的能力。单点登录允许用户认证一次就可以获得多个系统的服务。这是通过JAAS的认证授权机制以及Java GSSAPI在两个对等实体之间建立安全通信环境实现的。由于JAAS和JavaGSSAPI良好的封装性，将JAAS以及JavaGSSAPI应用到Hadoop中，可以在尽量少改动源代码的情况下实现Hadoop安全。
作为Hadoop最早的使用者之一，Yahoo!率先在Hadoop安全方面做出了贡献。通过引入kerberos作为底层的认证授权机制，Yahoo!在用户认证，用户访问远程服务的授权，以及用户访问控制方面实现了一部分Hadoop安全。
本文的首要目标是使用kerberos作为底层安全机制，在用户任务提交、运行，以及HDFS文件访问控制方面实现Hadoop安全。
问题明确
本节明确本文需要研究的内容和解决问题可能的方法。
研究Hadoop的任务提交、分发机制。
研究kerberos的具体机制，认证方法以及相应的名词。
研究kerberos安装及使用方法。对kerberos安装，用户使用以及管理员使用分别作出一定的描述。
研究JAAS和JavaGSSAPI原理和使用方法。
Kerberos认证过程
Kerberos的三个子过程
通过以上的介绍，我们基本上了解了整个Kerberos authentication的整个流程：整个流程大体上包含以下3个子过程：
Client向KDC申请TGT（Ticket Granting Ticket）。
Client通过获得TGT向DKC申请用于访问Server的Ticket。
Client最终向为了Server对自己的认证向其提交Ticket。
不过上面的介绍离真正的Kerberos Authentication还是有一点出入。Kerberos整个认证过程通过3个sub-protocol来完成。这个3个Sub-Protocol分别完成上面列出的3个子过程。这3个sub-protocol分别为：
AuthenticationService Exchange
TicketGranting Service Exchange
Client/ServerExchange
下图简单展示了完成这个3个Sub-protocol所进行Message Exchange。
1． Authentication Service Exchange
通过这个Sub-protocol，KDC（确切地说是KDC中的AuthenticationService）实现对Client身份的确认，并颁发给该Client一个TGT。具体过程如下：
Client向KDC的AuthenticationService发送Authentication Service Request（KRB_AS_REQ）,为了确保KRB_AS_REQ仅限于自己和KDC知道，Client使用自己的Master Key对KRB_AS_REQ的主体部分进行加密（KDC可以通过Domain的Account Database获得该Client的MasterKey）。KRB_AS_REQ的大体包含以下的内容：
Pre-authenticationdata：包含用以证明自己身份的信息。说白了，就是证明自己知道自己声称的那个account的Password。一般地，它的内容是一个被Client的Masterkey加密过的Timestamp。
Client name& realm: 简单地说就是Domain name\Client
Server Name：注意这里的Server Name并不是Client真正要访问的Server的名称，而我们也说了TGT是和Server无关的（Client只能使用Ticket，而不是TGT去访问Server）。这里的Server Name实际上是KDC的Ticket Granting Service的Server Name。
AS（Authentication Service）通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是否知道Client的Password。所以AS只需从AccountDatabase中提取Client对应的MasterKey对Pre-authentication data进行解密，如果是一个合法的Timestamp，则可以证明发送放提供的是正确无误的密码。验证通过之后，AS将一份AuthenticationService Response（KRB_AS_REP）发送给Client。KRB_AS_REQ主要包含两个部分：本Client的MasterKey加密过的Session Key（SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大体又包含以下的内容：
Session Key:SKDC-Client：Logon Session Key
Client name& realm: 简单地说就是Domain name\Client
End time:TGT到期的时间。