在默认配置中,我们希望您确保攻击者无法通过限制所有网络访问来访问您的 Hadoop 集群。如果您希望对可以远程访问数据或提交工作的人员进行任何限制,则必须按照本文档中所述保护 Hadoop 集群的身份验证和访问。
当 Hadoop 配置为在安全模式下运行时,每个 Hadoop 服务和每个用户都必须通过 Kerberos 进行身份验证。
必须正确配置所有服务主机的正向和反向主机查找,以允许服务相互进行身份验证。可以使用 DNS 或 /etc/hosts
文件配置主机查找。建议在尝试在安全模式下配置 Hadoop 服务之前了解 Kerberos 和 DNS 的工作原理。
Hadoop 的安全功能包括 身份验证、服务级别授权、Web 控制台身份验证 和 数据机密性。
当服务级别身份验证开启时,最终用户必须在与 Hadoop 服务交互之前对其自身进行身份验证。最简单的方法是用户使用 Kerberos kinit
命令进行交互式身份验证。当使用 kinit
进行交互式登录不可行时,可以使用 Kerberos 密钥表文件进行编程身份验证。
确保 HDFS 和 YARN 守护程序以不同的 Unix 用户身份运行,例如 hdfs
和 yarn
。此外,确保 MapReduce JobHistory 服务器以不同的用户身份运行,例如 mapred
。
建议让他们共享一个 Unix 组,例如 hadoop
。另请参阅“从用户到组的映射”以了解组管理。
用户:组 | 守护程序 |
---|---|
hdfs:hadoop | NameNode、辅助 NameNode、JournalNode、DataNode |
yarn:hadoop | ResourceManager、NodeManager |
mapred:hadoop | MapReduce 作业历史记录服务器 |
每个 Hadoop 服务实例都必须配置其 Kerberos 主体和 Keytab 文件位置。
服务主体的常规格式为 ServiceName/[email protected]
。例如:dn/[email protected]
。
Hadoop 通过允许将服务主体的 hostname 组件指定为 _HOST
通配符来简化配置文件的部署。每个服务实例都将在运行时用自己的完全限定主机名替换 _HOST
。这允许管理员在所有节点上部署同一组配置文件。但是,Keytab 文件将有所不同。
每个 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)
该主机上的辅助 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)
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/[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 服务器 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)
Hadoop 使用 hadoop.security.auth_to_local
指定的规则将 Kerberos 主体映射到 OS 用户(系统)帐户。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 中定义)匹配时,选择主体名称的第一个组件作为系统用户名。例如,如果默认领域是 MYREALM.TLD
,则默认规则将主体 host/[email protected]
映射到系统用户 host
。
如果未指定任何规则,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 组映射。
实际上,您需要使用 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
设置一个非特权端口。1. 将 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,则它可以成功连接到以 root 身份验证或 SASL 身份验证运行的 DataNode。更改所有客户端的配置可确保 DataNode 上的后续配置更改不会中断应用程序。最后,可以通过更改其配置并重新启动来迁移每个单独的 DataNode。在迁移期间,暂时让一些 DataNode 以 root 身份验证运行,而另一些 DataNode 以 SASL 身份验证运行是可以接受的,因为启用了 SASL 的 HDFS 客户端可以连接到两者。
在 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 集群中更常使用。
Web 控制台和客户端之间的数据传输通过 SSL(HTTPS) 进行保护。建议进行 SSL 配置,但配置 Hadoop 安全性时不必使用 Kerberos。
要为 HDFS 守护程序的 Web 控制台启用 SSL,请在 hdfs-site.xml 中将 dfs.http.policy
设置为 HTTPS_ONLY
或 HTTP_AND_HTTPS
。请注意,KMS 和 HttpFS 不支持此参数。请参阅 Hadoop KMS 和 Hadoop HDFS over HTTP - 服务器设置,了解有关分别通过 HTTPS 启用 KMS 和通过 HTTPS 启用 HttpFS 的说明。
要为 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 和本地文件系统(所有节点上)的各种路径以及建议的权限
文件系统 | 路径 | 用户:组 | 权限 |
---|---|---|---|
本地 | dfs.namenode.name.dir |
hdfs:hadoop | drwx------ |
本地 | dfs.datanode.data.dir |
hdfs:hadoop | drwx------ |
本地 | $HADOOP_LOG_DIR |
hdfs:hadoop | drwxrwxr-x |
本地 | $YARN_LOG_DIR |
yarn:hadoop | drwxrwxr-x |
本地 | yarn.nodemanager.local-dirs |
yarn:hadoop | drwxr-xr-x |
本地 | yarn.nodemanager.log-dirs |
yarn:hadoop | drwxr-xr-x |
本地 | container-executor | root:hadoop | --Sr-s--* |
本地 | conf/container-executor.cfg |
root:hadoop | r-------* |
hdfs | / |
hdfs:hadoop | drwxr-xr-x |
hdfs | /tmp |
hdfs:hadoop | drwxrwxrwxt |
hdfs | /user |
hdfs:hadoop | drwxr-xr-x |
hdfs | yarn.nodemanager.remote-app-log-dir |
yarn:hadoop | drwxrwxrwxt |
hdfs | mapreduce.jobhistory.intermediate-done-dir |
mapred:hadoop | drwxrwxrwxt |
hdfs | mapreduce.jobhistory.done-dir |
mapred:hadoop | drwxr-x--- |
为了在 Hadoop 中启用 RPC 身份验证,请将 hadoop.security.authentication
属性的值设置为 "kerberos"
,并适当地设置下面列出的安全相关设置。
以下属性应位于群集中所有节点的 core-site.xml
中。
参数 | 值 | 备注 |
---|---|---|
hadoop.security.authentication |
kerberos |
simple : 无身份验证。(默认) kerberos : 通过 Kerberos 启用身份验证。 |
hadoop.security.authorization |
true |
启用 RPC 服务级授权。 |
hadoop.rpc.protection |
authentication |
authentication : 仅身份验证(默认);integrity : 除了身份验证之外的完整性检查; privacy : 除了完整性之外的数据加密 |
hadoop.security.auth_to_local |
RULE: exp1 RULE: exp2 … DEFAULT |
该值是包含换行符的字符串。有关 exp 的格式,请参阅 Kerberos 文档。 |
hadoop.proxyuser. superuser.hosts |
允许 superuser 访问模拟的逗号分隔主机。* 表示通配符。 | |
hadoop.proxyuser. superuser.groups |
由超级用户模拟的用户所属的逗号分隔组。* 表示通配符。 |
参数 | 值 | 备注 |
---|---|---|
dfs.block.access.token.enable |
true |
为安全操作启用 HDFS 块访问令牌。 |
dfs.namenode.kerberos.principal |
nn/[email protected] |
NameNode 的 Kerberos 主体名称。 |
dfs.namenode.keytab.file |
/etc/security/keytab/nn.service.keytab |
NameNode 的 Kerberos 密钥表文件。 |
dfs.namenode.kerberos.internal.spnego.principal |
HTTP/[email protected] |
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 密钥表文件。在 HA 集群中,此设置与 Journal 节点共享。 |
以下设置允许配置对 NameNode Web UI 的 SSL 访问(可选)。
参数 | 值 | 备注 |
---|---|---|
dfs.http.policy |
HTTP_ONLY 或HTTPS_ONLY 或HTTP_AND_HTTPS |
HTTPS_ONLY 关闭 http 访问。如果使用 SASL 对数据传输协议进行身份验证,而不是以 root 身份运行 DataNode 并使用特权端口,则必须将此属性设置为HTTPS_ONLY 以保证 HTTP 服务器的身份验证。(请参阅dfs.data.transfer.protection 。) |
dfs.namenode.https-address |
0.0.0.0:9871 |
此参数在非 HA 模式下且不使用联合时使用。有关详细信息,请参阅HDFS 高可用性和HDFS 联合。 |
参数 | 值 | 备注 |
---|---|---|
dfs.namenode.secondary.http-address |
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/[email protected] |
辅助 NameNode 的 Kerberos 主体名称。 |
dfs.secondary.namenode.kerberos.internal.spnego.principal |
HTTP/[email protected] |
备用 NameNode 用于 Web UI SPNEGO 身份验证的服务器主体。根据惯例,SPNEGO 服务器主体以前缀 HTTP/ 开头。如果值为 '*' ,Web 服务器将尝试使用密钥表文件 dfs.web.authentication.kerberos.keytab 中指定的每个主体登录。对于大多数部署,这可以设置为 ${dfs.web.authentication.kerberos.principal} ,即使用 dfs.web.authentication.kerberos.principal 的值。 |
参数 | 值 | 备注 |
---|---|---|
dfs.journalnode.kerberos.principal |
jn/[email protected] |
JournalNode 的 Kerberos 主体名称。 |
dfs.journalnode.keytab.file |
/etc/security/keytab/jn.service.keytab |
JournalNode 的 Kerberos 密钥表文件。 |
dfs.journalnode.kerberos.internal.spnego.principal |
HTTP/[email protected] |
当启用 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 密钥表文件。在 HA 集群中,此设置与 Name Node 共享。 |
dfs.journalnode.https-address |
0.0.0.0:8481 |
JournalNode 的 HTTPS Web UI 地址。 |
参数 | 值 | 备注 |
---|---|---|
dfs.datanode.data.dir.perm |
700 |
|
dfs.datanode.address |
0.0.0.0:1004 |
安全 DataNode 必须使用特权端口,以确保服务器安全启动。这意味着必须通过 jsvc 启动服务器。或者,如果使用 SASL 身份验证数据传输协议,则必须将其设置为非特权端口。(请参阅 dfs.data.transfer.protection 。) |
dfs.datanode.http.address |
0.0.0.0:1006 |
安全 DataNode 必须使用特权端口,以确保服务器安全启动。这意味着必须通过 jsvc 启动服务器。 |
dfs.datanode.https.address |
0.0.0.0:9865 |
Data Node 的 HTTPS Web UI 地址。 |
dfs.datanode.kerberos.principal |
dn/[email protected] |
DataNode 的 Kerberos 主体名称。 |
dfs.datanode.keytab.file |
/etc/security/keytab/dn.service.keytab |
DataNode 的 Kerberos 密钥表文件。 |
dfs.encrypt.data.transfer |
false |
使用数据加密时设置为 true |
dfs.encrypt.data.transfer.algorithm |
使用数据加密时,可以将其设置为 3des 或 rc4 以控制加密算法 | |
dfs.encrypt.data.transfer.cipher.suites |
使用数据加密时,可以将其设置为 AES/CTR/NoPadding 以激活 AES 加密 | |
dfs.encrypt.data.transfer.cipher.key.bitlength |
使用数据加密时,可以将其设置为 128 、192 或 256 以控制使用 AES 时的密钥位长度 | |
dfs.data.transfer.protection |
authentication :仅认证;integrity :除了认证之外的完整性检查;privacy :除了完整性之外的数据加密。此属性默认为未指定。设置此属性会为数据传输协议的认证启用 SASL。如果启用此属性,则dfs.datanode.address 必须使用非特权端口,dfs.http.policy 必须设置为 HTTPS_ONLY ,并且在启动 DataNode 进程时必须将 HDFS_DATANODE_SECURE_USER 环境变量设置为未定义。 |
参数 | 值 | 备注 |
---|---|---|
dfs.web.authentication.kerberos.principal |
http/[email protected] |
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 服务器的访问。 |
参数 | 值 | 备注 |
---|---|---|
yarn.resourcemanager.principal |
rm/[email protected] |
ResourceManager 的 Kerberos 主体名称。 |
yarn.resourcemanager.keytab |
/etc/security/keytab/rm.service.keytab |
ResourceManager 的 Kerberos 密钥表文件。 |
yarn.resourcemanager.webapp.https.address |
${yarn.resourcemanager.hostname}:8090 |
非 HA 的 RM Web 应用程序的 https 地址。在 HA 集群中,为每个 ResourceManager 使用 yarn.resourcemanager.webapp.https.address. rm-id。有关详细信息,请参见ResourceManager 高可用性。 |
参数 | 值 | 备注 |
---|---|---|
yarn.nodemanager.principal |
nm/[email protected] |
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.address |
0.0.0.0:8044 |
NM Web 应用程序的 https 地址。 |
WebAppProxy
在应用程序导出的 Web 应用程序和最终用户之间提供了一个代理。如果启用了安全性,它将在用户访问潜在不安全的 Web 应用程序之前发出警告。使用代理进行身份验证和授权的处理方式与任何其他特权 Web 应用程序一样。
参数 | 值 | 备注 |
---|---|---|
yarn.web-proxy.address |
WebAppProxy 主机: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/[email protected] |
WebAppProxy 的 Kerberos 主体名称。 |
YARN 框架使用的 ContainerExecutor
,该框架定义如何启动和控制任何“容器”。
Hadoop YARN 中提供以下内容
ContainerExecutor | 说明 |
---|---|
DefaultContainerExecutor |
YARN 用于管理容器执行的默认执行器。容器进程具有与 NodeManager 相同的 Unix 用户。 |
LinuxContainerExecutor |
此执行器仅在 GNU/Linux 上受支持,它将容器作为提交应用程序的 YARN 用户(在启用完全安全性时)或作为专用用户(在未启用完全安全性时默认为 nobody)运行。在启用完全安全性时,此执行器要求在启动容器的集群节点上创建所有用户帐户。它使用 Hadoop 发行版中包含的 setuid 可执行文件。NodeManager 使用此可执行文件启动和终止容器。setuid 可执行文件切换到提交应用程序的用户,并启动或终止容器。为了最大程度地提高安全性,此执行器设置了容器使用的本地文件和目录(例如共享对象、jar、中间文件、日志文件等)的受限权限和用户/组所有权。特别注意,正因为如此,除了应用程序所有者和 NodeManager 之外,没有其他用户可以访问任何本地文件/目录,包括作为分布式缓存的一部分本地化的文件/目录。 |
要构建 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
运行,该用户属于组 users
和 hadoop
,其中任何一个都是主组。还假设 users
既有 yarn
也有另一个用户(应用程序提交者)alice
作为其成员,并且 alice
不属于 hadoop
。根据上述描述,setuid/setgid 可执行文件应设置为 6050 或 --Sr-s---
,其中用户所有者为 yarn
,组所有者为 hadoop
,其成员为 yarn
(而不是 users
,后者除了 yarn
之外还有 alice
作为其成员)。
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
文件中。这些项应作为简单的键值对提及,每行一个
参数 | 值 | 备注 |
---|---|---|
yarn.nodemanager.linux-container-executor.group |
hadoop |
NodeManager 的 Unix 组。container-executor 二进制文件的组所有者应为该组。应与配置 NodeManager 的值相同。此配置是验证 container-executor 二进制文件的安全访问所必需的。 |
banned.users |
hdfs,yarn,mapred,bin |
禁止用户。 |
allowed.system.users |
foo,bar |
允许的系统用户。 |
min.user.id |
1000 |
防止其他超级用户。 |
总之,以下是 LinuxContainerExecutor
相关的各种路径所需的本地文件系统权限
文件系统 | 路径 | 用户:组 | 权限 |
---|---|---|---|
本地 | container-executor |
root:hadoop | --Sr-s--* |
本地 | conf/container-executor.cfg |
root:hadoop | r-------* |
本地 | yarn.nodemanager.local-dirs |
yarn:hadoop | drwxr-xr-x |
本地 | yarn.nodemanager.log-dirs |
yarn:hadoop | drwxr-xr-x |
参数 | 值 | 备注 |
---|---|---|
mapreduce.jobhistory.address |
MapReduce JobHistory Server host:port |
默认端口为 10020。 |
mapreduce.jobhistory.keytab |
/etc/security/keytab/jhs.service.keytab |
MapReduce JobHistory Server 的 Kerberos 密钥表文件。 |
mapreduce.jobhistory.principal |
jhs/[email protected] |
MapReduce JobHistory Server 的 Kerberos 主体名称。 |
每个主机在 DNS 中有多个主机名的多宿主机设置(例如,对应于公共和专用网络接口的不同主机名)可能需要额外的配置才能使 Kerberos 身份验证正常工作。请参阅HDFS 对多宿网络的支持
Kerberos 很难设置,更难调试。常见问题是
/etc/krb5.conf
)。JVM 的错误消息基本上没有意义,这无助于诊断和修复此类问题。
可以为客户端和任何服务启用额外的调试信息
将环境变量 HADOOP_JAAS_DEBUG
设置为 true
。
export HADOOP_JAAS_DEBUG=true
编辑 log4j.properties
文件,以 DEBUG
级别记录 Hadoop 的安全包。
log4j.logger.org.apache.hadoop.security=DEBUG
通过设置一些系统属性启用 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 客户端状态。
hadoop kdiag
该命令为成功的诊断运行返回状态代码 0。这并不意味着 Kerberos 正在工作,仅仅意味着 KDiag 命令没有从其有限的探测集中发现任何问题。特别是,由于它不尝试连接到任何远程服务,因此它不会验证客户端是否受到任何服务信任。
如果不成功,退出代码为
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 '/'
--jaas
:要求在 java.security.auth.login.config
中定义 JAAS 文件。如果设置了 --jaas
,则 Java 系统属性 java.security.auth.login.config
必须设置为 JAAS 文件;此文件必须存在,是非零字节的简单文件,并且当前用户可读。不会执行更详细的验证。
Hadoop 本身不需要 JAAS 文件,但某些服务(如 Zookeeper)在安全操作中需要它们。
--keylen <length>
: 要求 JVM 支持的加密密钥的最小大小”。如果 JVM 不支持此长度,则该命令将失败。
默认值为 256,这是 AES256
加密方案所需的。未安装 Java 加密扩展的 JVM 不支持此类密钥长度。除非配置为使用密钥长度较短的加密方案,否则 Kerberos 将不起作用。
--keytab <keytab> --principal <principal>
: 从 keytab 登录。以特定主体身份从 keytab 登录。
_HOST
到当前主机名的映射。--nofail
: 在第一个问题上不要失败KDiag 将尽最大努力诊断所有 Kerberos 问题,而不是在第一个问题上停止。
这在某种程度上受到限制;按问题出现的顺序进行检查(例如,首先检查密钥长度),因此早期失败可能会触发更多问题。但它确实会生成更详细的报告。
--nologin
: 不要尝试登录。跳过尝试登录。这优先于 --keytab
选项,并且还禁用尝试以当前已初始化的用户身份登录到 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 <resource>
: 要加载的 XML 配置资源。要加载 XML 配置文件,可以使用此选项。默认情况下,仅加载 core-default
和 core-site
XML 资源。当其他配置文件具有任何 Kerberos 相关配置时,这将有所帮助。
hadoop kdiag --resource hbase-default.xml --resource hbase-site.xml
要在操作期间进行额外日志记录,请将日志记录和 HADOOP_JAAS_DEBUG
环境变量设置为“故障排除”中列出的值。JVM 选项在 KDiag 中自动设置。
--secure
: 如果未在安全集群上执行命令,则失败。也就是说:如果集群的身份验证机制显式或隐式设置为“简单”
<property> <name>hadoop.security.authentication</name> <value>simple</value> </property>
不用说,如此配置的应用程序无法与安全 Hadoop 集群通信。
--verifyshortname <principal>
: 验证主体的简称这将验证主体的简称不包含 "@"
或 "/"
字符。
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
中