13.hadoop-2.7.2官网文档翻译-安全模式中的Hadoop

介绍

该文档描述了怎样配置Hadoop安全模式的认证。

默认情况下，Hadoop运行在非安全模式，实际上不需要认证。通过配置Hadoop运行在安全模式。为了使用Hadoop服务，每个用户和服务都需要Kerberos的认证。

Hadoop的安全特性包括： 认证 服务等级认证 web控制台认证 数据保密

认证

最终用户账户

当服务等级认证开始时，使用处于安全模式的Hadoop的最终用户需要被Kerberos认证。最简单认证的方式使用Kerberos的命令kinit。

Hadoop守护进程的用户账户

确保HDFS和YARN进程运行在不同的*nix用户，比如hdfs和yarn。确保MapReduce JobHistory server运行不同的用户如mapred。

推荐将他们放在同一个*nix组，比如，hadoop。群组管理请看从用户到组的映射

Hadoop守护进程和用户的Kerberos负责人

为了在Hadoop安全模式中运行Hadoop服务守护进程，Kerberos负责人是必须的，每个服务都会根据适当的权限读取保存在keytab文件内的认证信息

HTTP的web控制台应该被另一个主要的RPC提供服务。

下面会展示Hadoop服务认证的例子

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/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nn/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nn/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

Secondary NameNode主机上的Secondary 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/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 sn/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 sn/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

每台DataNode主机上的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/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 dn/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 dn/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

YARN

ResourceManager主机上的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/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 rm/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 rm/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

NodeManager 主机上的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/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nm/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 nm/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

MapReduce JobHistory server

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/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 jhs/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 jhs/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD (ArcFour with HMAC/md5)

kerberos负责人到系统用户账户的映射

Hadoop使用hadoop.security.auth_to_local（与kerberos配置文件（krb5.conf）的auth_to_local一样的方式）指定的规则将kerberos负责人映射到系统用户账户。 此外，Hadoop的auth_to_local映射支持/L标志，那小写字母返回的名字。

默认情况下，如果realm匹配到default_realm(通常定义在/etc/krb5.conf),会选负责人名字的第一部分作为用户名， 例如，默认规则是host/full.qualified.domain.name@REALM.TLD被映射到host。

自定义规则可以使用 hadoop kerbname命令测试。该命令允许你指定一个负责人，并支持Hadoop当前auth_to_local的规则集。

将用户映射到组

尽管HDFS上文件被关联到所有人和组，Hadoop自己没有定义组。将用户映射到组是被OS或者LDAP完成的。

可以通过指定映射程序的名字作为hadoop.security.group.mapping的值来改变映射的方式。详情请看HDFS权限指南

事实上，你需要在Hadoop安全模式中用LDAP使用kerberos管理SSO环境。

代理用户

一些产品如Apache Oozie代表最终用户访问Hadoop的服务需要可以模仿最终用户才行。详情请看代理用户文档

安全的DataNode

因为DataNode的数据传输协议没有使用Hadoop的RPC框架，DataNode会使用dfs.datanode.address和dfs.datanode.http.address指定的特有端口验证她自己。该验证基于假设攻击者不能获得root特权。’

当你作为root用户执行hdfs datanode命令，服务进程首先会绑定特权端口。然后带着特权，运行HADOOP_SECURE_DN_USER指定的用户账户。启动进程会使用JSVC_HOME处的jsvc。在启动时必须指定HADOOP_SECURE_DN_USER和JSVC_HOME作为环境变量(在hadoop-env.sh)。

跟2.6.0版本一样，SASL（Simple Authentication and Security Layer）用来验证数据传输协议。在该配置中，对于安全集群不再需要作为root用户使用ysvc和绑定特权端口来启动DataNode。为了在数据传输协议上启用SASL，设置hdfs-site.xml中的dfs.data.transfer.protection，为dfs.datanode.address设置非特权端口，将dfs.http.policy设置到HTTPS_ONLY。 并确保HADOOP_SECURE_DN_USER环境变量没有定义。

注意：如果dfs.datanode.address设置到特权端口，就不能讲SASL使用在数据传输协议上。这就是要向后兼容的原因。

为了将一个现有的集群从使用root认证迁移到开始使用SASL。首先确保集群的所有节点都是部署的2.6.0版本及以上，同时没有任何外部应用连接到集群。只有2.6.0及以后版本的HDFS客户端可以使用SASL作为数据传输协议的验证连接到DataNode。因此在迁移之前所有的调用者使用正确的版本是至关重要的。在部署了2.6.0或更新版本后，更新所有的外部应用配置来启用SASL。 如果HDFS客户端启用了SASL，那么就可以成功连接到不管是运行root验证还是SASL验证的DataNode上了。 保证所有客户端的配置先更改，随后DataNode上的配置更改将不会使应用程序混乱。 最后，每个单独的DataNode可以通过更改配置并重启来迁移。在迁移期间，暂时允许一部分DataNode运行root验证，一部分DataNode运行SASL验证的混合状态，因为HDFS客户端启用了SASL，两种方式都能连接。

数据保密性

RPC数据加密

Hadoop服务端和客户端间的数据传输。在core-site.xml中将hadoop.rpc.protection设置为privacy,可以激活数据加密。

块数据传输上的数据加密

需要将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中指定的算法仍然在初始化key交换期间使用。AES 的key位长可以通过设置dfs.encrypt.data.transfer.cipher.key.bitlength为128,192或256进行配置。默认为128位。

AES提供最大的加密强度和最佳的性能。此时，3DES和RC4在Hadoop集群中更常用。

HTTP上的数据加密

web控制台和客户端之间的数据传输受SSL保护。

配置

允许HDFS和本地文件系统路径

下表中列举了HDFS和本地文件系统中多种路径和推荐的权限：

通用配置

为了启用Hadoop上的RPC验证，将hadoop.security.authentication属性值设置为kerberos,并设置适当的下面列出的安全相关设置

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

NameNode

Secondary NameNode

DataNode

WebHDFS

ResourceManager

NodeManager

Configuration for WebAppProxy

WebAppProxy提供了应用程序暴露的web应用和最终用户间的代理。如果启用了安全模式，在用户进入潜在的不安全的web应用时会有提醒。使用代理的认证和授权被其他的特定web应用管理。

LinuxContainerExecutor

ContainerExecutor被YARN框架使用来定义任何容器的启动和控制。

下面是YARN可获得Executor：

为了构建LinuxContainerExecutor可执行，运行：

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

` -Dcontainer-executor.conf.dir内的路径应该是setuid执行配置文件所在的集群节点的路径，该执行文件应该安装在 $HADOOP_YARN_HOME/bin`。

该执行文件必须有指定权限6050 或者--Sr-s---，用户为root用户，组为NodeManager的unix用户所在的没有普通应用用户的指定的组，比如hadoop。如果任何应用用户属于该指定组，安全将会被损坏。该指定组的名字应该在conf/yarn-site.xml和conf/container-executor.cfg的配置属性yarn.nodemanager.linux-container-executor.group中指定。

比如，NodeManager以用户yarn的身份运行，该用户是hadoop组的用户，并属于主组。用户yarn和其他用户alice(应用提交这)都是它的成员，alice不属于hadoop组。如上描述setuid/getuid执行应该被设置为6050或--Sr-s---，用户为yarn，组为hadoop，而且yarn为hadoop的组成员（alice不是hadoop成员）

LinuxTaskController需要路径包含和引导到yarn.nodemanager.local-dirs和yarn.nodemanager.log-dirs指定的目录在目录的权限表conf/container-executor.cfg中设置755权限。

该执行文件需要名为container-executor.cfg的配置文件通过mvn在配置目录提取。

配置文件需要被运行NodeManager的用户所拥有（用户yarn），组属于任何人，而且权限位0400或r--------。

执行文件需要从conf/container-executor.cfg文件提取出来的如下配置条目。如下条目应该以简单的k-v形式存在，每行一个。

这是本地文件系统权限的linuxcontainerexecutor相关的各种路径的要求：

MapReduce JobHistory Server

• 上一篇
  09.hadoop-2.7.2官网文档翻译-Hadoop命令行微型集群
• 下一篇
  14.hadoop-2.7.2官网文档翻译-服务级别的授权指南

「游客及非Github用户留言」：

「Github登录用户留言」：