安全模式

最终用户帐户

打开服务级别身份验证后，最终用户必须先对自己进行身份验证，然后才能与Hadoop服务进行交互。最简单的方法是使用户使用Kerberos kinit命令进行交互身份验证。如果无法通过kinit进行交互式登录，则可以使用使用Kerberos keytab文件的程序身份验证。

Hadoop守护程序的用户帐户

确保HDFS和YARN守护程序以不同的Unix用户身份运行，例如hdfs和yarn。另外，请确保MapReduce JobHistory服务器以不同的用户身份（例如mapred）运行。

建议让他们共享一个Unix组，例如hadoop。另请参阅“ 从用户到组的映射 ”以进行组管理。

Hadoop守护程序的Kerberos主体

必须为每个Hadoop Service实例配置其Kerberos主体和keytab文件位置。

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

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

$ klist -e -k -t /etc/security/keytab/nn.service.keytab
密钥表名称：FILE：/etc/security/keytab/nn.service.keytab
KVNO时间戳负责人
   4 07/18/11 21:08:09 nn/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 nn/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   4 07/18/11 21:08:09 nn/full.qualified.domain.name@REALM.TLD（带有HMAC / md5的ArcFour）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   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
密钥表名称：FILE：/etc/security/keytab/sn.service.keytab
KVNO时间戳负责人
   4 07/18/11 21:08:09 sn/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 sn/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   4 07/18/11 21:08:09 sn/full.qualified.domain.name@REALM.TLD（ArcHour with HMAC / md5）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   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
密钥表名称：FILE：/etc/security/keytab/dn.service.keytab
KVNO时间戳负责人
   4 07/18/11 21:08:09 dn/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 dn/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   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（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   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
密钥表名称：FILE：/etc/security/keytab/rm.service.keytab
KVNO时间戳负责人
   4 07/18/11 21:08:09 rm/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 rm/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   4 07/18/11 21:08:09 rm/full.qualified.domain.name@REALM.TLD（ArcHour with HMAC / md5）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   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
密钥表名称：FILE：/etc/security/keytab/nm.service.keytab
KVNO时间戳负责人
   4 07/18/11 21:08:09 nm/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 nm/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   4 07/18/11 21:08:09 nm/full.qualified.domain.name@REALM.TLD（带有HMAC / md5的ArcFour）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   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
密钥表名称：FILE：/etc/security/keytab/jhs.service.keytab
KVNO时间戳负责人
   4 07/18/11 21:08:09 jhs/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 jhs/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   4 07/18/11 21:08:09 jhs/full.qualified.domain.name@REALM.TLD（ArcHour with HMAC / md5）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-256 CTS模式）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（具有96位SHA-1 HMAC的AES-128 CTS模式）
   4 07/18/11 21:08:09 host/full.qualified.domain.name@REALM.TLD（ArcFour with HMAC / md5）

从Kerberos主体映射到OS用户帐户

Hadoop使用hadoop.security.auth_to_local指定的规则将Kerberos主体映射到OS用户（系统）帐户。Hadoop如何评估这些规则取决于hadoop.security.auth_to_local.mechanism的设置。

在默认的hadoop模式下，必须将Kerberos主体与将主体转换为简单形式的规则（即，用户帐户名不带'@'或'/'）相匹配，否则主体将不被授权，并且将记录错误。在的情况下，MIT模式的规则以同样的方式作为工作auth_to_local在Kerberos配置文件（krb5.conf）的限制和Hadoop的模式也并不适用。如果使用MIT模式，建议使用/etc/krb5.conf中指定的相同auth_to_local规则作为默认领域的一部分，并使它们保持同步。在两个Hadoop中和MIT模式，规则将应用于所有主体（DEFAULT除外），无论其指定的领域如何。此外，请注意您应该不依赖auth_to_local规则ACL，并使用正确的（OS）的机制。

auth_to_local的可能值为：

• RULE：exp本地名称将从exp制定。exp的格式为[n：string]（regexp）s / pattern / replacement / g。整数n指示目标主体应具有多少个组件。如果此匹配，则将由字符串组成一个字符串，将主体的领域替换为$ 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中定义）匹配时，才选择主体名称的第一部分作为系统用户名。例如，如果默认领域为MYREALM.TLD，则默认规则将主体host/full.qualified.domain.name@MYREALM.TLD映射到系统用户主机。

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

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

规则范例

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

<属性>
  <name> hadoop.security.auth_to_local </ name>
  <值>
    规则：[2：$ 1 / $ 2 @ $ 0]（[ndj] n /.*@ REALM。\ TLD）s /.*/ hdfs /
    规则：[2：$ 1 / $ 2 @ $ 0]（[rn] m /.*@ REALM \ .TLD）s /.*/ yarn /
    规则：[2：$ 1 / $ 2 @ $ 0]（jhs /.*@ REALM \ .TLD）s /.*/ mapred /
    默认
  </ value>
</ property>

这会将任何主机上的任何主体nn，dn，jn从领域REALM.TLD映射到本地系统帐户hdfs。其次，将映射任何主要RM，纳米任何关于主机从REALM.TLD到本地系统帐户纱线。第三，它将任何主机上的主体jhs从领域REALM.TLD映射到本地系统mapred。最后，默认领域中任何主机上的任何主体都将映射到该主体的用户组件。

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

从用户到组的映射

可以通过hadoop.security.group.mapping配置系统用户到系统组的映射机制。有关详细信息，请参见Hadoop组映射。

实际上，您需要在安全模式下使用Kerberos和LDAP for Hadoop管理Kerberos的SSO环境。

代理用户

代表最终用户访问Hadoop服务的某些产品（例如Apache Oozie）需要能够模拟最终用户。有关详细信息，请参见代理用户的文档。

安全数据节点

因为DataNode数据传输协议不使用Hadoop RPC框架，所以DataNodes必须使用dfs.datanode.address和dfs.datanode.http.address指定的特权端口对自己进行身份验证。该身份验证基于以下假设：攻击者将无法获得DataNode主机上的root特权。

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

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

为了迁移使用根身份验证的现有群集，改而开始使用SASL，请首先确保已将2.6.0或更高版本部署到所有群集节点以及需要连接到该群集的任何外部应用程序。只有版本2.6.0和更高版本的HDFS客户端可以连接到使用SASL进行数据传输协议身份验证的DataNode，因此至关重要的是，所有调用者在迁移之前都必须具有正确的版本。在将2.6.0版或更高版本部署到各处后，请更新所有外部应用程序的配置以启用SASL。如果为SASL启用了HDFS客户端，则它可以成功连接到以根身份验证或SASL身份验证运行的DataNode。更改所有客户端的配置可确保随后对DataNode进行的配置更改不会中断应用程序。最后，可以通过更改其配置并重新启动来迁移每个单独的DataNode。在此迁移期间，暂时混合使用根身份验证运行的某些数据节点和通过SASL身份验证运行的某些数据节点是可以接受的，因为启用了SASL的HDFS客户端可以同时连接到这两者。

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

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

HTTP上的数据加密

Web控制台和客户端之间的数据传输通过使用SSL（HTTPS）保护。建议使用SSL配置，但使用Kerberos配置Hadoop安全性不是必需的。

要启用HDFS守护进程，一套Web控制台SSL dfs.http.policy要么HTTPS_ONLY或HTTP_AND_HTTPS在HDFS-site.xml中。注意KMS和HttpFS不遵守此参数。有关分别启用HTTPS上的KMS和HTTPS上的HttpFS的说明，请参阅基于HTTP的Hadoop KMS和Hadoop HDFS- 服务器设置。

为了使纱线守护程序，一套Web控制台SSL yarn.http.policy到HTTPS_ONLY纱-site.xml中。

要为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 Web UI的SSL访问（可选）。

次要名称节点

JournalNode

数据节点

WebHDFS

资源管理器

节点管理器

WebAppProxy的配置

所述WebAppProxy提供由应用程序和终端用户导出的web应用程序之间的代理。如果启用了安全性，它将在访问可能不安全的Web应用程序之前警告用户。使用代理的身份验证和授权与其他任何特权Web应用程序一样进行处理。

LinuxContainerExecutor

甲ContainerExecutor使用YARN框架，它限定任何如何容器推出和控制。

Hadoop YARN中提供了以下内容：

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

 $ mvn软件包-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运行的，后者是用户users和hadoop组的一部分，其中任何一个都是主要组。还使用户既具有yarn又具有另一个用户（应用程序提交者）alice作为其成员，并且alice不属于hadoop。由上面的描述中去，所述的setuid / setgid的可执行应设置6050或--SR-S ---具有用户拥有者作为纱线和基团的所有者的hadoop具有纱线作为其构件（而不是用户具有翘也是除yarn之外的成员）。

LinuxTaskController要求将包含并通向yarn.nodemanager.local-dirs和yarn.nodemanager.log-dirs中指定的目录的路径设置为755权限，如上表中目录权限所述。

• conf / container-executor.cfg

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

配置文件必须由运行NodeManager的用户拥有（在上例中为user yarn），任何人都归组，并且应具有权限0400或r --------。

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

概括一下，这是与LinuxContainerExecutor相关的各种路径所需的本地文件系统权限：

MapReduce JobHistory服务器

用法

KDiag：诊断Kerberos问题
  [-D键=值]：定义配置选项。
  [--jaas]：要求在java.security.auth.login.config中定义一个JAAS文件。
  [--keylen <keylen>]：要求最小大小是JVM支持的加密密钥。默认值：256
  [--keytab <keytab> --principal <principal>]：以特定的主体身份从keytab登录。
  [--nofail]：不要在第一个问题上失败。
  [--nologin]：请勿尝试登录。
  [--out <文件>]：将输出写入文件。
  [--resource <资源>]：加载XML配置资源。
  [--secure]：要求hadoop配置安全。
  [--verifyshortname <principal>]：验证特定主体的简称不包含'@'或'/'

hadoop kdiag --out out.txt

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

hadoop kdiag-资源hbase-default.xml-资源hbase-site.xml

<属性>
  <name> hadoop.security.authentication </ name>
  <value>简单</ value>
</ property>

例

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

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