一、可能的安全问题
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