Hadoop安全模式

终端用户账户

当服务级别认证开启时，终端用户在与Hadoop服务交互前必须进行身份验证。最简单的方式是用户通过Kerberos kinit命令进行交互式认证。当无法使用kinit进行交互式登录时，可采用基于Kerberos密钥表文件的编程式认证。

Hadoop守护进程的用户账户

确保HDFS和YARN守护进程以不同的Unix用户身份运行，例如hdfs和yarn。同时，确保MapReduce JobHistory服务器以不同用户身份运行，例如mapred。

建议让它们共享一个Unix组，例如hadoop。另请参阅"Mapping from user to group"了解组管理。

Hadoop守护进程的Kerberos主体

每个Hadoop服务实例都必须配置其Kerberos主体和密钥表文件位置。

服务主体的通用格式为 ServiceName/_HOST@REALM.TLD。例如 dn/_HOST@EXAMPLE.COM。

Hadoop通过允许将服务主体的主机名部分指定为_HOST通配符，简化了配置文件的部署。每个服务实例在运行时都会将_HOST替换为其自己的完全限定主机名。这使得管理员可以在所有节点上部署相同的配置文件集。不过，密钥表文件将会不同。

$ 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)

$ 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)

$ 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)

$ 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)

$ 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)

$ 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主体映射到操作系统用户(系统)账户。Hadoop评估这些规则的方式由hadoop.security.auth_to_local.mechanism的设置决定。

在默认的hadoop模式下，Kerberos主体必须匹配一个将其转换为简单形式的规则（即不包含"@"或"/"的用户账户名），否则该主体将无法获得授权并会记录错误。而在MIT模式下，这些规则的工作方式与Kerberos配置文件(krb5.conf)中的auth_to_local相同，且不受hadoop模式的限制。如果使用MIT模式，建议采用与/etc/krb5.conf中默认域相同的auth_to_local规则，并保持同步。无论在hadoop还是MIT模式下（DEFAULT除外），这些规则都适用于所有主体，无论其指定域为何。另外请注意，不应将auth_to_local规则作为ACL依赖，而应使用适当的（操作系统）机制。

auth_to_local 的可能取值为：

• RULE:exp 本地名称将根据exp表达式生成。exp的格式为[n:string](regexp)s/pattern/replacement/g。整数n表示目标主体应包含的组件数量。若匹配成功，将根据string字符串生成新字符串，其中主体领域替换为$0，主体的第n个组件替换为$n（例如，若主体是johndoe/admin，则[2:$2$1foo]将生成字符串adminjohndoefoo）。若该字符串与regexp正则表达式匹配，则会在字符串上执行s//[g]替换命令。可选参数g将使替换操作在整个字符串范围内全局生效，而非仅替换第一个匹配项。作为对MIT的扩展，Hadoop的auth_to_local映射支持/L标志，该标志会将返回的名称转换为小写。

• DEFAULT 当且仅当领域与default_realm（通常在/etc/krb5.conf中定义）匹配时，选取主体名称的第一个组件作为系统用户名。例如，默认规则将主体host/full.qualified.domain.name@MYREALM.TLD映射到系统用户host，前提是默认领域是MYREALM.TLD。

如果未指定任何规则，Hadoop默认使用DEFAULT，这可能对大多数集群来说并不合适。

请注意，Hadoop不支持多个默认领域（例如像Heimdal那样）。此外，Hadoop不会验证映射是否存在本地系统账户。

示例规则

在典型集群中，HDFS和YARN服务将分别以系统用户hdfs和yarn身份启动。hadoop.security.auth_to_local可按如下方式配置：

<property>
  <name>hadoop.security.auth_to_local</name>
  <value>
    RULE:[2:$1/$2@$0]([ndj]n/.*@REALM.\TLD)s/.*/hdfs/
    RULE:[2:$1/$2@$0]([rn]m/.*@REALM\.TLD)s/.*/yarn/
    RULE:[2:$1/$2@$0](jhs/.*@REALM\.TLD)s/.*/mapred/
    DEFAULT
  </value>
</property>

这将把来自域REALM.TLD中任何host上的主体nn, dn, jn映射到本地系统账户hdfs。其次，它将把来自REALM.TLD中任何host上的主体rm, nm映射到本地系统账户yarn。第三，它将把来自域REALM.TLD中任何host上的主体jhs映射到本地系统账户mapred。最后，来自默认域中任何主机上的任何主体都将被映射到该主体的用户组件。

可以使用hadoop kerbname命令测试自定义规则。该命令允许用户指定一个主体并应用Hadoop当前的auth_to_local规则集。

用户到组的映射

系统用户到系统组的映射机制可以通过hadoop.security.group.mapping进行配置。详情请参阅Hadoop Groups Mapping。

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

代理用户

一些产品如Apache Oozie代表终端用户访问Hadoop服务时，需要能够模拟终端用户身份。详情请参阅代理用户文档。

安全数据节点

由于DataNode数据传输协议不使用Hadoop RPC框架，DataNode必须通过特权端口进行身份验证，这些端口由dfs.datanode.address和dfs.datanode.http.address指定。这种验证机制基于一个假设：攻击者无法获取DataNode主机上的root权限。

当以root身份执行hdfs datanode命令时，服务器进程会先绑定特权端口，然后降低权限并以HDFS_DATANODE_SECURE_USER指定的用户账户运行。此启动过程使用安装到JSVC_HOME的jsvc程序。您必须在启动时将HDFS_DATANODE_SECURE_USER和JSVC_HOME指定为环境变量（在hadoop-env.sh中）。

从2.6.0版本开始，SASL可用于认证数据传输协议。在此配置中，安全集群不再需要使用jsvc以root用户启动DataNode并绑定特权端口。要启用数据传输协议的SASL认证，请在hdfs-site.xml中设置dfs.data.transfer.protection。启用SASL的DataNode可以通过以下两种方式在安全模式下启动：1. 为dfs.datanode.address设置非特权端口；2. 将dfs.http.policy设为HTTPS_ONLY，或将dfs.datanode.http.address设为特权端口，并确保在启动时（在hadoop-env.sh中）正确指定HDFS_DATANODE_SECURE_USER和JSVC_HOME环境变量。

为了将现有使用root认证的集群迁移至采用SASL认证，首先需确保2.6.0或更高版本已部署到所有集群节点以及需要连接集群的外部应用程序。只有2.6.0及以上版本的HDFS客户端才能连接到使用SASL进行数据传输协议认证的DataNode，因此在迁移前确保所有调用方都具备正确版本至关重要。当所有环境都部署2.6.0或更高版本后，更新外部应用程序配置以启用SASL。若HDFS客户端启用了SASL，则无论DataNode运行的是root认证还是SASL认证，客户端都能成功连接。为所有客户端修改配置可确保后续DataNodes的配置变更不会影响应用程序运行。最后，通过修改配置并重启的方式逐个迁移每个DataNode。在迁移期间暂时允许部分DataNode运行root认证、部分运行SASL认证的混合状态，因为启用SASL的HDFS客户端可以同时兼容这两种认证方式。

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中指定的算法。可以通过将dfs.encrypt.data.transfer.cipher.key.bitlength设置为128、192或256来配置AES密钥位长度。默认值为128。

AES提供了最强的加密强度和最佳性能。目前，3DES和RC4在Hadoop集群中使用更为频繁。

您还可以将dfs.encrypt.data.transfer.cipher.suites设置为SM4/CTR/NoPadding来启用SM4加密。默认情况下，此参数未指定。SM4密钥位长度可通过设置dfs.encrypt.data.transfer.cipher.key.bitlength为128、192或256来配置，默认值为128。

HTTP数据加密

Web控制台与客户端之间的数据传输通过SSL(HTTPS)进行保护。虽然配置SSL不是启用Hadoop与Kerberos安全集成的必要条件，但仍建议进行SSL配置。

要为HDFS守护进程的Web控制台启用SSL，请在hdfs-site.xml中将dfs.http.policy设置为HTTPS_ONLY或HTTP_AND_HTTPS。请注意KMS和HttpFS不遵循此参数。有关分别在HTTPS上启用KMS和在HTTPS上启用HttpFS的说明，请参阅Hadoop KMS和Hadoop HDFS over HTTP - Server Setup。

要为YARN守护进程的Web控制台启用SSL，请在yarn-site.xml中将yarn.http.policy设置为HTTPS_ONLY。

要为MapReduce JobHistory服务器的Web控制台启用SSL，请在mapred-site.xml中将mapreduce.jobhistory.http.policy设置为HTTPS_ONLY。

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

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

通用配置

要在hadoop中启用RPC认证，请将hadoop.security.authentication属性的值设置为"kerberos"，并适当配置下面列出的安全相关设置。

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

NameNode

以下设置允许配置对NameNode Web界面的SSL访问（可选）。

Secondary NameNode

JournalNode

DataNode

WebHDFS

ResourceManager

NodeManager

WebAppProxy 配置

WebAppProxy 在应用程序导出的Web应用与终端用户之间提供代理服务。如果启用了安全机制，它会在用户访问可能存在风险的Web应用前发出警告。通过该代理进行的身份验证和授权处理方式与其他特权Web应用相同。

LinuxContainerExecutor

一个由YARN框架使用的ContainerExecutor，用于定义如何启动和控制任何容器。

以下是Hadoop YARN中可用的功能：

要构建LinuxContainerExecutor可执行文件，请运行：

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

传入-Dcontainer-executor.conf.dir的路径应该是集群节点上setuid可执行文件配置文件所在的路径。该可执行文件应安装在$HADOOP_YARN_HOME/bin目录中。

可执行文件必须具备特定权限：6050或--Sr-s---权限，由root（超级用户）拥有用户所有权，并由特殊组（例如hadoop）拥有组所有权，其中NodeManager Unix用户是该组成员，且普通应用程序用户不属于该组。如果任何应用程序用户属于此特殊组，安全性将受到威胁。这个特殊组名应在conf/yarn-site.xml和conf/container-executor.cfg中为配置属性yarn.nodemanager.linux-container-executor.group指定。

例如，假设NodeManager以用户yarn身份运行，该用户属于users和hadoop组中的任意一个主要组。同时假设users组包含yarn和另一个用户（应用提交者）alice作为其成员，而alice不属于hadoop组。根据上述描述，setuid/setgid可执行文件应设置为6050或--Sr-s---权限，用户所有者设为yarn，组所有者设为hadoop（该组包含yarn作为成员，而不选择同时包含alice和yarn的users组）。

LinuxTaskController要求yarn.nodemanager.local-dirs和yarn.nodemanager.log-dirs中指定的目录路径及其上级目录需设置755权限，如上文目录权限表格所述。

• conf/container-executor.cfg

可执行文件需要一个名为container-executor.cfg的配置文件，该文件必须存在于传递给上述mvn目标的配置目录中。

配置文件必须由运行NodeManager的用户拥有（上述示例中的用户yarn），组所有者可以是任何人，并且应具有0400或r--------的权限。

可执行文件需要在conf/container-executor.cfg配置文件中包含以下配置项。这些配置项应以简单的键值对形式列出，每行一个：

总结一下，以下是LinuxContainerExecutor相关路径所需的本地文件系统权限：

MapReduce JobHistory 服务器

使用说明

KDiag: Diagnose Kerberos Problems
  [-D key=value] : Define a configuration option.
  [--jaas] : Require a JAAS file to be defined in java.security.auth.login.config.
  [--keylen <keylen>] : Require a minimum size for encryption keys supported by the JVM. Default value : 256.
  [--keytab <keytab> --principal <principal>] : Login from a keytab as a specific principal.
  [--nofail] : Do not fail on the first problem.
  [--nologin] : Do not attempt to log in.
  [--out <file>] : Write output to a file.
  [--resource <resource>] : Load an XML configuration resource.
  [--secure] : Require the hadoop configuration to be secure.
  [--verifyshortname <principal>]: Verify the short name of the specific principal does not contain '@' or '/'

hadoop kdiag --out out.txt

hadoop kdiag --keytab zk.service.keytab --principal zookeeper/devix.example.org@REALM > out.txt 2>&1

hadoop kdiag --resource hbase-default.xml --resource hbase-site.xml

<property>
  <name>hadoop.security.authentication</name>
  <value>simple</value>
</property>

示例

hadoop kdiag \
  --nofail \
  --resource hdfs-site.xml --resource yarn-site.xml \
  --keylen 1024 \
  --keytab zk.service.keytab --principal zookeeper/devix.example.org@REALM

此操作尝试执行所有诊断而不提前失败，加载HDFS和YARN的XML资源，要求最小密钥长度为1024字节，并以主体zookeeper/devix.example.org@REALM身份登录，其密钥必须位于密钥表zk.service.keytab中