Hadoop安全

  Hadoop集群搭建之初默认信任操作系统的认证结果，无法判断哪个用户是固定超级用户，能够登录集群并执行任务的用户都被认作是集群的超级管理员，所有用户对集群资源都具有相同的访问权限。集群内所有节点都是可靠值得信赖的，MapReduce和Spark计算任务能够访问集群内的任意数据资源，几乎没有任何安全措施，存在安全风险。

授权控制

  Apache官方推荐按服务划分账号的方式对Hadoop集群进行精细化权限控制，即对特定服务或资源，只有特定用户能够进行访问，如下所示。

  整个Hadoop集群服务进程分别跑在hdfs，yarn，mapred三个用户下，都属于hadoop组中。

  集群节点上本地文件系统中HDFS和YARN相关文件的访问权限设置和HDFS上服务相关路径的权限设置。
  授权访问机制仅能够有效避免善良用户的误操作，却不能阻止来自Hadoop集群内部恶意用户的威胁。恶意用户能够很容易避开这种访问授权控制，访问Hadoop服务提交恶意作业，因DataNode节点没有访问控制，尽管HDFS会进行全路径检查，一旦知道文件块blockId，恶意用户便会绕过访问控制机制直接从DataNode中读取或写入任意数据，严重破坏HDFS上数据的完整性，恶意用户还有可能伪装成集群中的服务器向用户供虚假服务，没有可靠的认证保障机制访问控制策略形同虚设。

Kerberos节点认证

  Kerberos协议由MIT（麻省理工学院）首创，现已成为被业界广泛接受的标准，用于网络中机器间的相互认证(Authentication)。Kerberos采用计算速度快的对称加密算法，在每对建立连接的两台机器之间使用临时共享密钥加密整个会话过程，具有相当高的安全性。
  Hadoop集群认证机制一共分为四个子过程，分别是Authentication Service Exchang，Ticket Granting Service Exchange，Client/Server Exchange[30]和User2User这四个子协议，如图所示。

  图中存在三种角色：KDC（Key Distribution Center，密钥分发中心），客户端（Client）和Hadoop服务器集群。其中KDC在整个Kerberos认证机制中起着非常重要的作用，节点认证过程中向客户端和Hadoop集群提供安全认证服务，由两个独立的逻辑部分组成，AS（Authentication Service，认证服务）和TGS（Ticket Granting Service，票据授权服务）。KDC维护一个存储所有认证账户的密钥数据库（Account Database），客户端和Hadoop集群分别与KDC共享一套只有它们双方才知道的密钥对，认证过程通过这三种角色协作完成。
  Client在使用Hadoop集群中的服务资源之前需要向KDC申请TGT（Ticket Granting Ticket，票据授予权），如图中过程①所示。客户端向KDC中的AS发送使用只有自己和KDC知道的主密钥加密后的KRB_AS_REQ（Authentication Service Request，认证服务请求），请求中包含能够证明身份的信息，一个被自己主密钥加密过的时间戳，以及提供所请求Hadoop服务的服务器账户名。AS收到客户端的认证请求之后对其进行身份验证，AS首先使用客户端的主密钥对加密过的时间戳进行解密，并与系统当前时间比较，满足可接受的时间范围，验证通过。TGS向客户端返回KRB_AS_RE（Authentication Service Response，认证服务响应），响应中包含使用客户端主密钥加密的称之为SKDC-Client的临时会话密钥（在配置文件中配置为7天），出于KDC维护临时会话密钥的复杂性，此密钥均由各节点维护提供。以及一个使用KDC自己的主密钥加密过的TGT，TGT中主要包含SKDC-Client，一个过期时间以及客户端信息。客户端对收到的响应进行解密得到SKDC-Client，认证执行过程②。
  过程②被执行之后，Client就拥有了Hadoop集群Server节点和KDC之间的属于服务节点的TGT。如果该TGT存在于节点缓存中，则Server直接将其返回给客户端，否则通过过程①的步骤去KDC服务器获得它和KDC之间的SKDC-Server和一个封装了这个SKDC-Server并被KDC的主密钥进行加密的TGT，将之缓存下来。
  客户端获得Hadoop服务节点的TGT之后，向KDC发送KRB_TGS_REQ（Ticket Granting Service Request，授权服务请求），请求中包含Hadoop服务节点的TGT，客户端自己的TGT和使用SKDC-Client加密之后的身份证明。TGS接收到KRB_TGS_REQ之后，对属于客户端和KDC之间的TGT进行解密得到SKDC-Client，之后使用SKDC-Client解密客户端加密之后的身份证明信息验证客户端是否是TGT的真正拥有方。验证通过之后，TGS对属于Hadoop服务节点和KDC之间的TGT进行解密，得到SKDC-Server，并使用该SKDC-Server对Ticket加密，Ticket中包含客户端和Hadoop服务节点间之的SServer-Client临时会话密钥和一个过期时间。TGS向客户端返回KRB_TGS_RE（Ticket Granting Service Response，票据授权服务响应），响应中包含使用SKDC-Client加密过后的客户端和Hadoop服务器的临时会话密钥SServer-Client和Ticket。客户端收到响应之后使用SKDC-Client解密得到SServer-Client。以上是整个过程③的算法。
  过程④是客户端和Hadoop服务节点的相互认证过程，所有请求无须再通过KDC进行。客户端向Hadoop服务节点发送KRB_AP_REQ（Application Service Request，服务请求），请求包含过程③获得的Ticket和使用SServer-Client加密之后的身份证明，KRB_AP_REQ中还包含双方是否需要双向验证的标识字段。Hadoop服务节点接收到KRB_AP_REQ之后，通过自己和KDC之间的临时会话密钥SKDC-Server解密Ticket，得到SServer-Client，之后使用SServer-Client解密客户端加密之后的身份证明对其进行身份验证。如果客户端要求进行双向认证，Hadoop服务节点需使用SServer-Client加密客户端身份证明中的时间戳，并将其发送给客户端用于验证自己的身份。验证成功之后客户端就能够使用请求的服务资源，以上任何一个阶段验证失败，此次服务请求失败。
  以上算法可以看出时间戳在整个认证机制中起到非常重要的作用，Kerberos默认要求时间差在300s内才进行认证，否则直接返回认证失败。因此必须使Kerberos集群和整个Hadoop集群保持时间同步，通过将ntpdate任务添加到crontab执行计划中可实现时间自动同步。
  Kerberos有两个配置属性，ticket_lifetime和renew_lifetime，ticket_lifetime配置凭证的生效时限，凭证过期之后，Kerberos的安全认证服务将无法提供。另一个属性renew_lifetime用来配置凭证失效后能够被延期的最长失效延期时间。认证过程还需要解决的问题就是采用哪种凭证过期处理策略。显然给ticket_lifetime和renew_lifetime属性配置长的时限间隔并不是可行的方案，解决方法将kinit加入到crontab执行计划中在每个续约期间对凭证进行自动续约。客户端程序凭证过期处理方法是使用Keytab文件自动续约，Keytab文件中记录着用户的身份凭证，使用Keytab文件做认证还能够实现免密码认证。