Hadoop安全机制探究

一、可能的安全问题

1、如果Hadoop服务不对用户或者服务进行认证，那么可能发生什么安全问题？

HDFS文件权限检查被规避
攻击者可以伪装服务，对集群进行攻击

2、因为只需要BlockId即可读取节点的数据，而DataNode不强制对任何访问请求做访问控制。那么，任何人都可以随意的访问和读写HDFS数据，这样就存在安全隐患。

二、Apache Hadoop安全团队使用的安全机制

基于Kerberos的安全机制，而不是SSL

原因：
1、Kerberos 使用对称秘钥操作，比使用公钥操作的SSL快几个量级，可以获得更好的性能。
2、通过使用集中化管理的Kerberos KDC(key distribution center)使得用户管理更简单。例如对一个用户进行销户，只需在KDC中删除该用户即可。而SSL需要生成一个吊销证书，并将其广播到所有服务器上去。

三、RPC连接时的认证体现

在Hadoop中客户端需要通过RPC来连接服务。对于已认证的集群，连接RPC需要使用SASL(Sample Authentication And Security Layer)。并且SASL需要协商子协议，Hadoop支持Kerberos（通过GSSAPI）和DIGEST-MD5认证协议。

除了NameNode服务之外，绝大多数Hadoop服务只支持Kerberos认证。

Kerberos机制：用户获取服务的Ticket并使用SASL/GSSAPI进行认证。
DIGEST-MD5机制：客户端和服务端共享一个秘钥，来相互认证（意味着往返）。这比Kerberos代价要小一些，因为不需要第三部分（例如KDC）的参与。

每当应用创建RPC连接的时候，要么使用token（如果token是可用的），要么使用Kerberos ticket进行认证。在通过RPC连接服务的过程中，客户端会加载ticket缓存中的Kerberos tickets用于Kerberos认证。MapReduce这样的服务也会创建token缓存，供task加载，用于连接TaskTracker获取数据、状态等。

四、Hadoop具体安全机制的体现

1、HDFS安全机制

客户端和HDFS服务之间的通信体现在两个方面，一个是客户端和NameNode之间建立连接。另一个是客户端和DataNode之间的块传输。

建立连接可以通过Kerberos也可以通过delegation token。后者在client和NameNode之间共享秘钥，这可以使得后续的已认证过的访问无需使用Kerberos Key Servers，但是为了获得一个delegation token，client和NameNode之间必须使用一个已认证的Kerberos连接。

另一方面，块传输是通过block access token来认证的，block access token由NameNode产生，并且每个块都有对应的block access token。

1）、delegation token和Kerberos ticket比较

如果要使用Kerberos认证，必须要从KDC获得delegated TGT (ticket granting ticket)，这也就是上边提到的第三方的参与。也就是说，你们需要到我这个KDC服务器来取“入场券”。或者是delegated service ticket，这个在使用上和delegation token有点相似，它也不需要在线连接KDC。但是Java GSS-API不支持service ticket delegation。这里可以看出一点，如果有大量的任务（MapR