Hadoop 文档

General

Common

HDFS

MapReduce

MapReduce REST APIs

YARN

YARN REST APIs

YARN Service

Submarine

Hadoop Compatible File Systems

Auth

Tools

Reference

Configuration

介绍

本文档介绍了如何在安全模式下为Hadoop配置身份验证。将Hadoop配置为以安全模式运行时,每个Hadoop服务和每个用户都必须通过Kerberos进行身份验证。

必须正确配置所有服务主机的正向和反向主机查找,以允许服务彼此进行身份验证。可以使用DNS或/ etc / hosts文件配置主机查找。在尝试以安全模式配置Hadoop服务之前,建议您具有Kerberos和DNS的工作知识。

Hadoop的安全功能包括身份验证服务级别授权Web控制台身份验证数据机密性

认证方式

最终用户帐户

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

Hadoop守护程序的用户帐户

确保HDFS和YARN守护程序以不同的Unix用户身份运行,例如hdfsyarn。另外,请确保MapReduce JobHistory服务器以不同的用户身份(例如mapred)运行

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

用户:组 守护进程
hdfs:hadoop NameNode,次要NameNode,JournalNode,DataNode
纱:纱 ResourceManager,NodeManager
mapred:hadoop MapReduce JobHistory服务器

Hadoop守护程序的Kerberos主体

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

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

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

HDFS

每个NameNode主机上的NameNode键表文件应如下所示:

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

该主机上的Secondary NameNode keytab文件应如下所示:

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

每个主机上的DataNode keytab文件应如下所示:

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

ResourceManager主机上的ResourceManager密钥表文件应如下所示:

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

每个主机上的NodeManager keytab文件应如下所示:

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

MapReduce JobHistory服务器

该主机上的MapReduce JobHistory Server密钥表文件应如下所示:

$ 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_localKerberos配置文件(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服务将分别作为系统hdfsyarn用户启动。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.addressdfs.datanode.http.address指定的特权端口对自己进行身份验证。该身份验证基于以下假设:攻击者将无法获得DataNode主机上的root特权。

当您以root用户身份执行hdfs datanode命令时,服务器进程首先绑定特权端口,然后放弃特权并以HDFS_DATANODE_SECURE_USER指定的用户帐户运行。此启动过程使用安装到JSVC_HOME 的jsvc程序。您必须在启动时(在hadoop-env.sh中)将HDFS_DATANODE_SECURE_USERJSVC_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_USERJSVC_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设置为3desrc4来选择特定的加密算法。如果未指定,则使用系统上配置的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_ONLYHTTP_AND_HTTPS在HDFS-site.xml中。注意KMS和HttpFS不遵守此参数。有关分别启用HTTPS上的KMS和HTTPS上的HttpFS的说明,请参阅基于HTTP的Hadoop KMSHadoop HDFS- 服务器设置

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

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

组态

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

下表列出了HDFS和本地文件系统(在所有节点上)的各种路径以及建议的权限:

文件系统 路径 用户:组 权限
本地 dfs.namenode.name.dir hdfs:hadoop drwx ------
本地 dfs.datanode.data.dir hdfs:hadoop drwx ------
本地 $ HADOOP_LOG_DIR hdfs:hadoop xwxrwxr-x
本地 $ YARN_LOG_DIR 纱:纱 xwxrwxr-x
本地 yarn.nodemanager.local-dirs 纱:纱 drwxr-xr-x
本地 yarn.nodemanager.log目录 纱:纱 drwxr-xr-x
本地 容器执行器 根:hadoop --Sr-s-*
本地 conf / container-executor.cfg 根:hadoop r ------- *
高清文件 / hdfs:hadoop drwxr-xr-x
高清文件 / tmp hdfs:hadoop w
高清文件 /用户 hdfs:hadoop drwxr-xr-x
高清文件 yarn.nodemanager.remote-app-log-dir 纱:纱 w
高清文件 mapreduce.jobhistory.intermediate-done-dir mapred:hadoop w
高清文件 mapreduce.jobhistory.done-dir mapred:hadoop drwxr-x--

常用配置

为了在hadoop中打开RPC身份验证,请将hadoop.security.authentication属性的值设置为“ kerberos”,并适当地设置下面列出的与安全性相关的设置。

以下属性应位于集群中所有节点的core-site.xml中。

参数 笔记
hadoop.security.authentication kerberos 简单:无需身份验证。(默认)   kerberos:通过Kerberos启用身份验证。
hadoop.security.authorization 真正 启用RPC服务级别授权
hadoop.rpc。保护 认证方式 authentication:仅认证(默认);完整性:除身份验证外的完整性检查; 隐私:数据加密除完整性
hadoop.security.auth_to_local 规则:exp1 规则:exp2  默认 该值是包含换行符的字符串。有关exp的格式,请参见Kerberos文档
hadoop.proxyuser。超级用户.hosts 逗号分隔的主机,可以从这些主机模拟超级用户访问。*表示通配符。
hadoop.proxyuser。超级用户.groups 超级用户模拟的用户所属的逗号分隔的组。*表示通配符。

名称节点

参数 笔记
dfs.block.access.token.enable 真正 启用HDFS块访问令牌以进行安全操作。
dfs.namenode.kerberos.principal nn/_HOST@REALM.TLD NameNode的Kerberos主体名称。
dfs.namenode.keytab.file /etc/security/keytab/nn.service.keytab NameNode的Kerberos密钥表文件。
dfs.namenode.kerberos.internal.spnego.principal HTTP/_HOST@REALM.TLD NameNode用于Web UI SPNEGO身份验证的服务器主体。SPNEGO服务器主体按照约定以前缀HTTP /开头。如果值为'*',则Web服务器将尝试使用密钥表文件dfs.web.authentication.kerberos.keytab中指定的每个主体登录。对于大多数部署,可以将其设置为$ {dfs.web.authentication.kerberos.principal},即使用dfs.web.authentication.kerberos.principal的值。
dfs.web.authentication.kerberos.keytab /etc/security/keytab/spnego.service.keytab NameNode的SPNEGO密钥表文件。在高可用性群集中,此设置与日志节点共享。

以下设置允许配置对NameNode Web UI的SSL访问(可选)。

参数 笔记
dfs.http.policy HTTP_ONLYHTTPS_ONLYHTTP_AND_HTTPS HTTPS_ONLY关闭http访问。此选项优先于已弃用的配置dfs.https.enable和hadoop.ssl.enabled。如果使用SASL来认证数据传输协议,而不是以root用户身份运行DataNode并使用特权端口,则必须将此属性设置为HTTPS_ONLY以保证对HTTP服务器的认证。(请参阅dfs.data.transfer.protection。)
dfs.namenode.https地址 0.0.0.0:9871 此参数用于非HA模式且没有联盟。有关详细信息,请参见HDFS高可用性HDFS联合
dfs.https.enable 真正 不建议使用该值。使用dfs.http.policy

次要名称节点

参数 笔记
dfs.namenode.secondary.http地址 0.0.0.0:9868 辅助NameNode的HTTP Web UI地址。
dfs.namenode.secondary.https-address 0.0.0.0:9869 辅助NameNode的HTTPS Web UI地址。
dfs.secondary.namenode.keytab.file /etc/security/keytab/sn.service.keytab 辅助NameNode的Kerberos密钥表文件。
dfs.secondary.namenode.kerberos.principal sn/_HOST@REALM.TLD 辅助NameNode的Kerberos主体名称。
dfs.secondary.namenode.kerberos.internal.spnego.principal HTTP/_HOST@REALM.TLD 辅助NameNode用于Web UI SPNEGO身份验证的服务器主体。SPNEGO服务器主体按照约定以前缀HTTP /开头。如果值为'*',则Web服务器将尝试使用密钥表文件dfs.web.authentication.kerberos.keytab中指定的每个主体登录。对于大多数部署,可以将其设置为$ {dfs.web.authentication.kerberos.principal},即使用dfs.web.authentication.kerberos.principal的值。

JournalNode

参数 笔记
dfs.journalnode.kerberos.principal jn/_HOST@REALM.TLD JournalNode的Kerberos主体名称。
dfs.journalnode.keytab.file /etc/security/keytab/jn.service.keytab JournalNode的Kerberos密钥表文件。
dfs.journalnode.kerberos.internal.spnego.principal HTTP/_HOST@REALM.TLD 启用Kerberos安全性时,JournalNode用于Web UI SPNEGO身份验证的服务器主体。SPNEGO服务器主体按照约定以前缀HTTP /开头。如果值为'*',则Web服务器将尝试使用密钥表文件dfs.web.authentication.kerberos.keytab中指定的每个主体登录。对于大多数部署,可以将其设置为$ {dfs.web.authentication.kerberos.principal},即使用dfs.web.authentication.kerberos.principal的值。
dfs.web.authentication.kerberos.keytab /etc/security/keytab/spnego.service.keytab JournalNode的SPNEGO密钥表文件。在高可用性群集中,此设置与名称节点共享。
dfs.journalnode.https地址 0.0.0.0:8481 JournalNode的HTTPS Web UI地址。

数据节点

参数 笔记
dfs.datanode.data.dir.perm 700
dfs.datanode.address 0.0.0.0:1004 Secure DataNode必须使用特权端口,以确保服务器已安全启动。这意味着必须通过jsvc启动服务器。或者,如果使用SASL来认证数据传输协议,则必须将其设置为非特权端口。(请参阅dfs.data.transfer.protection。)
dfs.datanode.http.address 0.0.0.0:1006 Secure DataNode必须使用特权端口,以确保服务器已安全启动。这意味着必须通过jsvc启动服务器。
dfs.datanode.https.address 0.0.0.0:9865 数据节点的HTTPS Web UI地址。
dfs.datanode.kerberos.principal dn/_HOST@REALM.TLD DataNode的Kerberos主体名称。
dfs.datanode.keytab.file /etc/security/keytab/dn.service.keytab DataNode的Kerberos密钥表文件。
dfs.encrypt.data.transfer 使用数据加密时 设置为true
dfs.encrypt.data.transfer.algorithm 使用数据加密控制加密算法时,可以 选择设置为3desrc4
dfs.encrypt.data.transfer.cipher.suites 使用数据加密时,可以选择设置为AES / CTR / NoPadding以激活AES加密
dfs.encrypt.data.transfer.cipher.key.bitlength 任选地设置为128192256使用AES数据加密时控制密钥位长度
dfs.data.transfer.protection 认证:仅认证;完整性:除身份验证外的完整性检查;隐私:除了完整性以外的数据加密默认情况下,未指定此属性。设置此属性将启用SASL进行数据传输协议的身份验证。如果启用此功能,则dfs.datanode.address必须使用非特权端口,dfs.http.policy必须设置为HTTPS_ONLY,并且在启动DataNode进程时必须未定义HDFS_DATANODE_SECURE_USER环境变量。

WebHDFS

参数 笔记
dfs.web.authentication.kerberos.principal http/_HOST@REALM.TLD WebHDFS的Kerberos主体名称。在HA群集中,JournalNode经常使用此设置,以确保通过SPNEGO对JournalNode HTTP服务器的访问。
dfs.web.authentication.kerberos.keytab /etc/security/keytab/http.service.keytab WebHDFS的Kerberos密钥表文件。在HA群集中,此设置通常用于JournalNode,以通过SPNEGO保护对JournalNode HTTP服务器的访问。

资源管理器

参数 笔记
纱线资源经理原则 rm/_HOST@REALM.TLD ResourceManager的Kerberos主体名称。
yarn.resourcemanager.keytab /etc/security/keytab/rm.service.keytab ResourceManager的Kerberos密钥表文件。
yarn.resourcemanager.webapp.https。地址 $ {yarn.resourcemanager.hostname}:8090 非HA的RM Web应用程序的https地址。在HA群集中,使用yarn.resourcemanager.webapp.https.address。每个ResourceManager的rm-id。有关详细信息,请参见ResourceManager高可用性

节点管理器

参数 笔记
纱线节点经理原则 nm/_HOST@REALM.TLD NodeManager的Kerberos主体名称。
yarn.nodemanager.keytab /etc/security/keytab/nm.service.keytab NodeManager的Kerberos密钥表文件。
yarn.nodemanager.container-executor.class org.apache.hadoop.yarn.server.nodemanager.LinuxContainerExecutor 使用LinuxContainerExecutor。
yarn.nodemanager.linux-container-executor.group Hadoop NodeManager的Unix组。
yarn.nodemanager.linux-container-executor.path / path / to / bin / container-executor Linux容器执行程序的可执行文件的路径。
yarn.nodemanager.webapp.https。地址 0.0.0.0:8044 NM Web应用程序的https地址。

WebAppProxy的配置

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

参数 笔记
yarn.web-proxy.address WebAppProxy host:用于AM Web应用程序代理的端口。 host:port(如果它与yarn.resourcemanager.webapp.address相同)或未定义,则ResourceManager将运行代理,否则需要启动独立的代理服务器。
yarn.web-proxy.keytab /etc/security/keytab/web-app.service.keytab WebAppProxy的Kerberos密钥表文件。
yarn.web-proxy.principal wap/_HOST@REALM.TLD WebAppProxy的Kerberos主体名称。

LinuxContainerExecutor

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

Hadoop YARN中提供了以下内容:

容器执行器 描述
DefaultContainerExecutor YARN用于管理容器执行的默认执行器。容器进程与NodeManager具有相同的Unix用户。
LinuxContainerExecutor 仅在GNU / Linux上受支持,此执行程序以提交应用程序的YARN用户(启用完全安全性)或专用用户(默认为nobody)(未启用完全安全性)运行容器。启用完全安全性后,该执行程序要求在启动容器的群集节点上创建所有用户帐户。它使用setuidHadoop发行版中包含的可执行文件。NodeManager使用此可执行文件来启动和终止容器。setuid可执行文件切换到提交了应用程序的用户,并启动或杀死容器。为了获得最大的安全性,该执行程序对容器使用的本地文件和目录(例如共享对象,jar,中间文件,日志文件等)设置受限权限和用户/组所有权。特别注意,因此,除了应用程序作为所有者和NodeManager,其他任何用户都不能访问任何本地文件/目录,包括作为分布式缓存一部分本地化的文件/目录。

要构建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.xmlconf / container-executor.cfg中为配置属性yarn.nodemanager.linux-container-executor.group指定这个特殊的组名。

例如,假设NodeManager是作为用户yarn运行的,后者是用户usershadoop组的一部分,其中任何一个都是主要组。还使用户既具有yarn又具有另一个用户(应用程序提交者)alice作为其成员,并且alice不属于hadoop。由上面的描述中去,所述的setuid / setgid的可执行应设置6050或--SR-S ---具有用户拥有者作为纱线和基团的所有者的hadoop具有纱线作为其构件(而不是用户具有也是除yarn之外的成员)。

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

  • conf / container-executor.cfg

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

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

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

参数 笔记
yarn.nodemanager.linux-container-executor.group Hadoop NodeManager的Unix组。容器执行程序二进制文件的组所有者应为该组。应该与配置NodeManager的值相同。需要此配置来验证容器执行器二进制文件的安全访问。
被禁止的用户 hdfs,纱,映射,bin 禁止的用户。
allowed.system.users foo,bar 允许的系统用户。
最小用户ID 1000 防止其他超级用户。

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

文件系统 路径 用户:组 权限
本地 容器执行器 根:hadoop --Sr-s-*
本地 conf / container-executor.cfg 根:hadoop r ------- *
本地 yarn.nodemanager.local-dirs 纱:纱 drwxr-xr-x
本地 yarn.nodemanager.log目录 纱:纱 drwxr-xr-x

MapReduce JobHistory服务器

参数 笔记
mapreduce.jobhistory.address MapReduce JobHistory Server 主机:端口 默认端口为10020。
mapreduce.jobhistory.keytab /etc/security/keytab/jhs.service.keytab MapReduce JobHistory服务器的Kerberos密钥表文件。
mapreduce.jobhistory.principal jhs/_HOST@REALM.TLD MapReduce JobHistory服务器的Kerberos主体名称。

多宿主

其中每个主机在DNS中具有多个主机名(例如,对应于公共和专用网络接口的不同主机名)的多宿主设置可能需要其他配置才能使Kerberos身份验证起作用。请参阅对多宿主网络的HDFS支持

故障排除

Kerberos很难设置,也很难调试。常见的问题是

  1. 网络和DNS配置。
  2. 主机上的Kerberos配置(/etc/krb5.conf)。
  3. Keytab的创建和维护。
  4. 环境设置:JVM,用户登录,系统时钟等。

来自JVM的错误消息实际上是毫无意义的,这无助于诊断和解决此类问题。

可以为客户端和任何服务启用额外的调试信息

将环境变量HADOOP_JAAS_DEBUG设置为true

导出HADOOP_JAAS_DEBUG = true

编辑log4j.properties文件以在DEBUG级别记录Hadoop的安全包。

log4j.logger.org.apache.hadoop.security =调试

通过设置一些系统属性来启用JVM级调试。

export HADOOP_OPTS =“-Djava.net.preferIPv4Stack = true -Dsun.security.krb5.debug = true -Dsun.security.spnego.debug”

使用KDiag进行故障排除

Hadoop具有帮助验证设置的工具:KDiag

它包含一系列探针JVM的配置和环境,转储出一些系统文件(/etc/krb5.conf中/etc/ntp.conf中),打印出一些系统状态,然后尝试登录到Kerberos作为当前用户或命名密钥表中的特定主体。

该命令的输出可用于本地诊断,或转发给支持群集的任何人。

KDiag命令有其自己的入口点; 通过将kdiag传递给bin / hadoop命令来调用它。因此,它将显示用于调用它的命令的kerberos客户端状态。

哈杜普·克迪亚格

该命令返回状态码0,以成功运行诊断。这并不意味着Kerberos正在工作—仅仅是KDiag命令没有从其有限的一组探测中识别出任何问题。特别是,由于它不尝试连接到任何远程服务,因此不验证客户端是否受任何服务信任。

如果失败,则退出代码为

  • -1:命令由于未知原因失败
  • 41:未经授权(== HTTP 401)。KDiag检测到导致Kerberos无法正常工作的情况。检查输出以识别问题。

用法

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>]:验证特定主体的简称不包含'@'或'/'

--jaas:需要在java.security.auth.login.config中定义一个JAAS文件。

如果设置了--jaas,则必须将Java系统属性java.security.auth.login.config设置为JAAS文件;否则,必须将Java属性设置为JAAS文件。该文件必须存在,是一个非零字节的简单文件,并且可由当前用户读取。不执行更详细的验证。

Hadoop本身不需要JAAS文件,但是某些服务(例如Zookeeper)确实需要它们以确保安全操作。

--keylen <length>:要求最小大小用于JVM支持的加密密钥”。

如果JVM不支持该长度,则该命令将失败。

根据AES256加密方案的需要,默认值为256 。未安装Java密码扩展的JVM不支持这样的密钥长度。除非配置为使用密钥长度较短的加密方案,否则Kerberos将无法工作。

--keytab <keytab> --principal <principal>:从密钥表登录。

从密钥表作为特定主体登录。

  1. 该文件必须包含特定的主体,包括任何命名的主机。也就是说,没有从_HOST到当前主机名的映射。
  2. KDiag将注销并尝试再次登录。这捕获了过去存在的JVM兼容性问题。(Hadoop的Kerberos支持要求对JVM特定的类进行使用/自检)。

--nofail:不要在第一个问题上失败

KDiag将尽力尝试诊断所有Kerberos问题,而不是在第一个问题上停下来。

这有点受限制;按照出现问题的顺序进行检查(例如,首先检查密钥长度),因此过早的故障可能引发更多问题。但是它确实产生了更详细的报告。

--nologin:不要尝试登录。

跳过尝试登录的步骤。这优先于--keytab选项,并且还禁止尝试以当前kinited用户身份登录kerberos。

当在应用程序中调用KDiag命令时,这很有用,因为它不会设置Hadoop的静态安全状态-仅检查一些基本的Kerberos前提条件。

--out outfile:将输出写入文件。

hadoop kdiag --out out.txt

许多诊断信息来自JRE(至stderr)和Log4j(至stdout)。要获取所有输出,最好将这两个输出流都重定向到同一文件,并省略--out选项。

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

即使在那儿,跨多个线程发出的两个流的输出也会有些混乱。实践将变得更加容易。在Log4j输出中查看线程名称以区分后台线程与主线程,这对hadoop级别有所帮助,但对JVM级别的日志记录无济于事。

--resource <资源>:要加载的XML配置资源。

要加载XML配置文件,可以使用此选项。默认情况下,仅加载core-defaultcore-site XML资源。当其他配置文件具有与Kerberos相关的任何配置时,这将有所帮助。

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

要在操作期间进行额外的日志记录,请将日志记录和HADOOP_JAAS_DEBUG环境变量设置为“疑难解答”中列出的值。JVM选项在KDiag中自动设置。

--secure:如果未在安全集群上执行命令,则失败。

即:如果群集的身份验证机制显式或隐式设置为“简单”:

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

不用说,如此配置的应用程序无法与安全的Hadoop集群通信。

--verifyshortname <principal>:验证主体的简称

这验证了主体的简称不包含“ @”“ /”字符。

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