Hadoop2.7.3安全模式-hadoop kerberos官方配置详解

介绍

这篇文档描述了如何为Hadoop在安全模式下配置认证。当Hadoop被配置运行在安全模式下时，每个Hadoop服务和每个用户都必须被Kerberos认证。正向方向的主机去查找所有服务的主机，必须被正确地配置来相互认证。主机查找可能都被配置在DNS或者/etc/hosts文件中。推荐你在尝试配置Hadoop安全模式前，先了解kerberos和DNS的工作原理。

Hadoop的安全特性，由Authentication（认证）, Service Level Authorization（服务级别认证）, (Authentication for Web Consoles)(http://hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-common/HttpAuthentication.html)（web控制台认证）和Data Confidentiality（数据保密）组成。

Authentication（认证）

终端用户帐号

当服务基本的认证开启时，终端用户必须在和Hadoop服务交互前认证。最简单的方式就是使用Kerberos的kinit命令来交互认证。使用Kerberos keytab文件的程序认证可能会在使用kinit的交互登录不可用时使用。

Hadoop进程的用户帐号

确认HDFS和YARN进程跑在不同的Unix用户下，比如：hdfs和yarn。还有，保证MapReduce JobHistory服务也跑在不同的用户之下，比如mapred。

推荐它们使用同一个Unix组，比如：hadoop。参考“Mapping from user to group”进行组的管理。

Hadoop进程的Kerberos principals（实体）

每个Hadoop服务实例都必须配置他的Kerberos principal和keytab文件位置。

一个服务实体的一般格式是：服务名/[email protected]。比如：dn/[email protected]。

Hadoop通过允许服务principal的主机组件被指定为_HOST通配符来简化配置文件的部署。每个服务实例都会用它们自己当前运行的合法主机名来代替_HOST。这就允许管理员给所有节点部署相同设置的配置文件。但是，keytab文件将会不同。

HDFS

NameNode在每个NameNode主机上的keytab文件，应该看起来像这样：

$ klist -e -k -t /etc/security/keytab/nn.service.keytab
Keytab name: FILE:/etc/security/keytab/nn.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 nn/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nn/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nn/[email protected] (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (ArcFour with HMAC/md5)

Seconday NameNode在主机上的keytab文件，应该看起来像这样：

$ klist -e -k -t /etc/security/keytab/sn.service.keytab
Keytab name: FILE:/etc/security/keytab/sn.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 sn/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 sn/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 sn/[email protected] (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (ArcFour with HMAC/md5)

DataNode在每个主机上的keytab文件, 应该看起来像这样:

$ klist -e -k -t /etc/security/keytab/dn.service.keytab
Keytab name: FILE:/etc/security/keytab/dn.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 dn/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 dn/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 dn/[email protected] (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (ArcFour with HMAC/md5)

YARN

在资源管理器（ResourceManager）主机上的资源管理器keytab文件，应该看起来像这样：

$ klist -e -k -t /etc/security/keytab/rm.service.keytab
Keytab name: FILE:/etc/security/keytab/rm.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 rm/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 rm/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 rm/[email protected] (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (ArcFour with HMAC/md5)

在每个主机上的节点管理器（NodeManager）的keytab文件，应该看起来像这样：

$ klist -e -k -t /etc/security/keytab/nm.service.keytab
Keytab name: FILE:/etc/security/keytab/nm.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 nm/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nm/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nm/[email protected] (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (ArcFour with HMAC/md5)

MapReduce JobHistory Server

在MapReduce JobHistory Server主机上的keytab文件，应该看起来像这样：

$ klist -e -k -t /etc/security/keytab/jhs.service.keytab
Keytab name: FILE:/etc/security/keytab/jhs.service.keytab
KVNO Timestamp         Principal
   4 07/18/11 21:08:09 jhs/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 jhs/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 jhs/[email protected] (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/[email protected] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/[email protected] (ArcFour with HMAC/md5)

映射Kerberos principals到操作系统用户账号

Hadoop使用被hadoop.security.auth_to_local指定的规则来映射kerberos principals到操作系统（系统）用户账号。这些规则使用和在 Kerberos configuration file (krb5.conf)中的auth_to_local相同的方式工作。另外，hadoop auth_to_local映射支持/L标志来是返回的名字小写。

默认会取principal名字的第一部分作为系统用户名如果realm匹配defaul_realm（通常被定义在/etc/krb5.conf）。比如：默认的的规则映射principal host/[email protected]到系统用户host。默认的规则可能对大多数的集群都不合适。

在一个典型的集群中，HDFS和YARN服务将分别由hdfs和yarn用户启动。hadoop.security.auth_to_local可以被配置成这样：

<property>
  <name>hadoop.security.auth_to_local</name>
  <value>
    RULE:[2:$1@$0](nn/.*@.*REALM.TLD)s/.*/hdfs/
    RULE:[2:$1@$0](jn/.*@.*REALM.TLD)s/.*/hdfs/
    RULE:[2:$1@$0](dn/.*@.*REALM.TLD)s/.*/hdfs/
    RULE:[2:$1@$0](nm/.*@.*REALM.TLD)s/.*/yarn/
    RULE:[2:$1@$0](rm/.*@.*REALM.TLD)s/.*/yarn/
    RULE:[2:$1@$0](jhs/.*@.*REALM.TLD)s/.*/mapred/
    DEFAULT
  </value>
</property>

自定义规则可以使用Hadoop kerbname命令测试，这个命令运行你指定一个principal并应用Hadoop当前的auth_to_local规则设置。

映射用户到组

系统用户到系统组的映射机制可以通过hadoop.security.group.mapping配置。更多细节查看HDFS Permissions Guide。

实际上，你需要在Hadoop安全模式中使用Kerberos with LDAP管理SSO(单点登录)环境。

代理用户

有些访问终端用户维护的Hadoop服务的产品，比如Apache Oozie，需要能够模拟终端用户。更多细节查看the doc of proxy user。

保护DataNode

因为DataNode的数据传输协议没有使用Hadoop RPC框架，DataNodes必须使用被dfs.datanode.address和dfs.datanode.http.address指定的特权端口来认证他们自己。该认证是基于假设攻击者无法获取在DataNode主机上的root特权。

当你使用root执行hdfs datanode命令时，服务器进程首先绑定特权端口，随后销毁特权并使用被HADOOP_SECURE_DN_USER指定的用户账号运行。这个启动进程使用被安装在JSVC_HOME的the jsvc program。你必须在启动项中（hadoop-env.sh）指定HADOOP_SECURE_DN_USER和JSVC_HOME做为环境变量。

2.6.0版本开始起，SASL可以被使用来认证数据传输协议。这不再需要安全集群使用jsvc的用户启动DataNode并绑定特权接口。要在数据传输协议上启用SASL，在hdfs-site.xml设置dfs.data.transfer.protection，为dfs.datanode.address设置一个免特权端口，设置dfs.http.policy to HTTPS_ONLY并保证HADOOP_SECURE_DN_USER环境变量没有设置。注意，如果dfs.datanode.address是设置了一个特权端口将不可能在数据传输协议上使用SASL。这是向后兼容的原因所要求的。

为了迁移一个存在的使用root认证的集群用使用SASL启动的方式替代。首先保证2.6.0或以上版本的hadoop已经被部署在所有的集群节点上，同时所有外部应用程序需要连接在这个集群上。只有2.6.0或以上版本的HDFS客户端可以使用SASL认证数据传输协议来连接DataNode。所以，在迁移前保证所有的节点版本正确是至关重要的。 所有地方的2.6.0或以上版本被部署之后，更新所有外部应用程序的配置来是SASL生效。如果以个HDFS客户端使用了SASL，那么他可以成功的连接一个DataNode，不管它使用的事root认证或者是SASL认证。配置所有的客户端保证以后在DataNode上的配置改变不会破坏这个应用程序。最后，每个DataNode个体都可以通过改变它的配置和重启来迁移。

数据保密

在RPC上的数据加密

在hadoop服务端和客户端之间传输的数据可以被加密。在core-site.xml上设置hadoop.rpc.protection隐私来激活加密。

块数据传输的数据加密

你需要在hdfs-site.xml上设置dfs.encrypt.data.transfer成true来激活为Datanode的数据传输协议的数据加密。

你可以选择性的设置dfs.encrypt.data.transfer.algorithm为3des或者rc4来选择使用特定的加密算法。如果不指定，那么在这个系统中，被配置的JCE将被默认使用，它通常情况使用3DES。

设置dfs.encrypt.data.transfer.cipher.suites成AES/CTR/NoPadding激活AES加密。默认情况下，这不被指定，所以AES不被使用。当AES被使用时，在一个初始密钥交换过程中被指定在dfs.encrypt.data.transfer.algorithm中的算法仍然被使用。AES密钥的长度可以通过设置dfs.encrypt.data.transfer.cipher.key.bitlength成128，192，或者256来配置。默认是128.

AES提供最大的加密强度和最佳的性能。目前，3DES和RC4已经经常在Hadoop集群中使用。

HTTP上的数据加密

在Web-console和客户端的数据传输被SSL(HTTPS)保护。SSL配置是推荐的，但是不需要使用kerberos配置Hadoop的安全。

配置

对于HDFS和本地文件系统路径的权限

下面的表格列出了各种HDFS和本地文件系统的路径（在所有节点上）和推荐的权限设置：

常见的配置

为了在Hadoop上开启RPC认证，设置hadoop.security.authentication的属性值为“kerberos”，并且合理地设置在下面列出的安全相关的配置项。

下面的属性应该在集群中所有节点的core-site.xml文件中。

NameNode

下面的设置允许配置SSL访问NameNode的web UI（可选）。

Secondary NameNode

JournalNode

DataNode

WebHDFS

ResourceManager

NodeManager

WebAppProxy配置

WebAppProxy在应用程序输出的web应用和一个终端用户之间提供一个代理。如果安全机制被启用，在用户访问一个潜在不安全的web应用时它会发出警告。认证和使用代理的认证和其他加密的web应用一样被处理。

LinuxContainerExecutor

一个被YARN框架使用的ContainerExecutor（容器执行者）定义了任何container如何被启动和控制。

下面在Hadoop YARN中是可用的：

构建LinuxContainerExecutor可执行文件，执行：

$ mvn package -Dcontainer-executor.conf.dir=/etc/hadoop/

这个可执行文件必须有特殊的权限：6050或者–Sr-s—权限被root用户所拥有（super-user）和被特殊组（比如：hadoop）所拥有，这个组中NodeManager Unix用户是他的成员并且没有其他普通应用用户。如果有其他应用的用户属于这个特殊的组，那么安全性就不能得到保证了。这个特殊的组的名字应该被指定在yarn.nodemanager.linux-container-executor.group配置属性中，conf/yarn-site.xml和conf/container-executor.cfg有需要。

比如，假设NodeManager使用yarn用户（是users和hadoop组的一部分，他们中的任何一个都是主要的组）运行。让users组中处理yarn还有另外一个用户alice（应用提交者），并且alice不在hadoop组中。根据以上的描述，setuid/setgid可执行文件一个被设置成6050或者–Sr-s—，user-owner是yarn，group-owner是hadoop，yarn是hadoop的成员（而不是users组，它出了yarn用户外还有一个alice的用户）。

LinuxTaskController要求被指定在yarn.nodemanager.local-dirs和yarn.nodemanager.log-dirs的包含路径和引导到的目录，它就像上面的表格中描述的一样被设置成775权限在权限路径上。

• conf/container-executor.cfg

这个可执行文件需要一个叫做container-executor.cfg的配置文件，在配置路径中出现，通过之前提到的MVN target。

这个配置文件必须被运行NodeManager的用户所拥有（比如上面例子中的yarn用户），被任何拥有0400或r——–权限的组所拥有。

这个可执行文件需要以下在conf/container-executor.cfg文件中出现的配置项。这些项目应该被要求成简单的key=value(键值对)，每一项一行。

复习一下，这里是本地文件系统各种与LinuxContainerExecutor相关的路径的权限要求：

MapReduce JobHistory Server

多宿主

多宿主（每个主机可能在DNS上有多个主机名，比如：不同的主机名对应公共和私有的网络接口）的设置，可需要额外的配置来使kerberos工作。查看HDFS Support for Multihomed Networks。

参考

1. O’Malley O et al. Hadoop Security Design
2. O’Malley O, Hadoop Security Architecture
3. Troubleshooting Kerberos on Java 7
4. Troubleshooting Kerberos on Java 8
5. Java 7 Kerberos Requirements
6. Java 8 Kerberos Requirements
7. Loughran S., Hadoop and Kerberos: The Madness beyond the Gate