3

我试图为我的CDH 4.3（通过 Cloudera Manager）测试台启用 Kerberos。因此，在 WebUI 中将身份验证从 Simple 更改为 Kerberos 后，我无法执行任何 hadoop 操作，如下所示。无论如何要明确指定密钥表吗？

[root@host-dn15 ~]# su - hdfs
-bash-4.1$ hdfs dfs -ls /
13/09/10 08:15:35 ERROR security.UserGroupInformation: PriviledgedActionException as:hdfs (auth:KERBEROS) cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
13/09/10 08:15:35 WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
13/09/10 08:15:35 ERROR security.UserGroupInformation: PriviledgedActionException as:hdfs (auth:KERBEROS) cause:java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
ls: Failed on local exception: java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]; Host Details : local host is: "host-dn15.hadoop.com/192.168.10.227"; destination host is: "host-dn15.hadoop.com":8020;
-bash-4.1$ kdestroy
-bash-4.1$ kinit
Password for hdfs@HADOOP.COM:
-bash-4.1$ klist
Ticket cache: FILE:/tmp/krb5cc_494
Default principal: hdfs@HADOOP.COM

Valid starting     Expires            Service principal
09/10/13 08:20:31  09/11/13 08:20:31  krbtgt/HADOOP.COM@HADOOP.COM
    renew until 09/10/13 08:20:31

-bash-4.1$ klist -e
Ticket cache: FILE:/tmp/krb5cc_494
Default principal: hdfs@HADOOP.COM

Valid starting     Expires            Service principal
09/10/13 08:20:31  09/11/13 08:20:31  krbtgt/HADOOP.COM@HADOOP.COM
    renew until 09/10/13 08:20:31, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
-bash-4.1$

于是我仔细查看了namenode日志，

2013-09-10 10:02:06,085 INFO org.apache.hadoop.ipc.Server: IPC Server listener on 8022: readAndProcess threw exception javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)] from client 10.132.100.228. Count of bytes read: 0
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)]

JCE 策略文件已安装在所有节点上。

[root@host-dn15 security]# sha256sum ./local_policy.jar
4a5c8f64107c349c662ea688563e5cd07d675255289ab25246a3a46fc4f85767  ./local_policy.jar
[root@host-dn15 security]# sha256sum ./US_export_policy.jar
b800fef6edc0f74560608cecf3775f7a91eb08d6c3417aed81a87c6371726115  ./US_export_policy.jar
[root@host-dn15 security]# sha256sum ./local_policy.jar.bak
7b26d0e16722e5d84062240489dea16acef3ea2053c6ae279933499feae541ab  ./local_policy.jar.bak
[root@host-dn15 security]# sha256sum ./US_export_policy.jar.bak
832133c52ed517df991d69770f97c416d2e9afd874cb4f233a751b23087829a3  ./US_export_policy.jar.bak
[root@host-dn15 security]#

以及领域中的负责人列表。

kadmin:  listprincs
HTTP/host-dn15.hadoop.com@HADOOP.COM
HTTP/host-dn16.hadoop.com@HADOOP.COM
HTTP/host-dn17.hadoop.com@HADOOP.COM
K/M@HADOOP.COM
cloudera-scm/admin@HADOOP.COM
hbase/host-dn15.hadoop.com@HADOOP.COM
hbase/host-dn16.hadoop.com@HADOOP.COM
hbase/host-dn17.hadoop.com@HADOOP.COM
hdfs/host-dn15.hadoop.com@HADOOP.COM
hdfs/host-dn16.hadoop.com@HADOOP.COM
hdfs/host-dn17.hadoop.com@HADOOP.COM
hdfs@HADOOP.COM
hue/host-dn15.hadoop.com@HADOOP.COM
host-dn16/hadoop.com@HADOOP.COM
kadmin/admin@HADOOP.COM
kadmin/changepw@HADOOP.COM
kadmin/host-dn15.hadoop.com@HADOOP.COM
krbtgt/HADOOP.COM@HADOOP.COM
mapred/host-dn15.hadoop.com@HADOOP.COM
mapred/host-dn16.hadoop.com@HADOOP.COM
mapred/host-dn17.hadoop.com@HADOOP.COM
root/admin@HADOOP.COM
root@HADOOP.COM
zookeeper/host-dn15.hadoop.com@HADOOP.COM
kadmin:  exit
[root@host-dn15 ~]#

导出了 hdfs 的 keytab 并用于 kinit。

-bash-4.1$ kinit -kt ./hdfs.keytab hdfs
-bash-4.1$ klist
Ticket cache: FILE:/tmp/krb5cc_494
Default principal: hdfs@HADOOP.COM

Valid starting     Expires            Service principal
09/10/13 09:49:42  09/11/13 09:49:42  krbtgt/HADOOP.COM@HADOOP.COM
    renew until 09/10/13 09:49:42

一切都是徒劳的。任何想法？？

提前谢谢，

4

1 回答 1

2

我遇到了一个问题，我有一个 Kerberized CDH 集群，即使使用有效的 Kerberos 票证，我也无法从命令行运行任何 hadoop 命令。

注意：写完这个答案后，我把它写成博客文章http://sarastreeter.com/2016/09/26/resolving-hadoop-problems-on-kerberized-cdh-5-x/。请分享！

所以即使有一张有效的票，这也会失败：

$ hadoop fs -ls /

WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

这是我学到的东西以及我最终如何解决问题。我已尽可能链接到当前版本的 Cloudera 文档，但某些文档似乎仅适用于旧版本。

请注意，问题归结为配置问题，但 Kerberos 本身和 Cloudera Manager 均已正确安装。我在寻找答案时遇到的许多问题都归结为 Kerberos 或 Hadoop 安装不正确。即使 Hadoop 和 Kerberos 都可以正常工作，但我没有将它们配置为正常协同工作，我也遇到了这个问题。

TL;博士

确保你有一张票

从您klist尝试执行 hadoop 命令的用户处执行。

$ sudo su - myuser
$ klist

如果您没有票，它将打印：

klist: Credentials cache file '/tmp/krb5cc_0' not found

如果您尝试在没有票证的情况下执行 hadoop 命令，您将GSS INITIATE FAILED设计错误：

WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

换句话说，这不是安装问题。如果这是您的情况，请查看：

CDH 默认 HDFS 用户和组限制

Cloudera 的默认安装对执行 hadoop 命令有用户和组限制，包括对某些用户的特定禁令（更多信息请参见 http://www.cloudera.com/documentation/enterprise/5-6-x/PDF第 57 页/cloudera-security.pdf）。

有几个属性可以处理这个问题，包括将 hdfs 的超组设置为字符串supergroup而不是hdfs，dfs_permissions enabled属性false默认设置为（hadoop 用户文件权限），禁止 uid 超过 1000 的用户。

其中任何一个都可能是一个因素，对我来说，HDFS 被列在了被禁止的用户属性中。

特别是对于用户 HDFS，如果您尝试使用 hdfs 执行 hadoop 命令，请确保您已从 hdfs-site.xml 配置中的banned.users 配置属性中删除了 hdfs。

  1) UNPRIVILEGED USER AND WRITE PERMISSIONS

Cloudera 推荐的执行 Hadoop 命令的方法是创建一个非特权用户和匹配的主体，而不是使用 hdfs 用户。一个问题是该用户还需要自己的/user目录，并且可能会遇到 /user 目录的写入权限错误。如果您的非特权用户在 中没有目录/user，则可能会导致 WRITE permissions denied 错误。

Cloudera 知识文章

http://community.cloudera.com/t5/CDH-Manual-Installation/How-to-resolve-quot-Permission-denied-quot-errors-in-CDH/ta-p/36141

  2) DATANODE PORTS AND DATA DIR PERMISSIONS

另一个相关问题是 Cloudera 在非 Kerberized 集群上将 dfs.datanode.data.dir 设置为 750，但在 Kerberized 集群上需要 700。如果设置了错误的 dir 权限，Kerberos 安装将失败。数据节点的端口也必须设置为低于 1024 的值，建议 HTTP 端口为 1006，Datanode 端口为 1004。

数据节点目录

http://www.cloudera.com/documentation/enterprise/5-6-x/topics/cdh_ig_hdfs_cluster_deploy.html

数据节点端口

http://www.cloudera.com/documentation/archive/manager/4-x/4-7-2/Configuring-Hadoop-Security-with-Cloudera-Manager/cmchs_enable_security_s9.html

  3) SERVICE-SPECIFIC CONFIGURATION TASKS

在安全文档的第 60 页，有对 Hadoop 服务进行 kerberize 的步骤。确保你做到了这些！

MapReduce 
$ sudo -u hdfs hadoop fs -chown mapred:hadoop ${mapred.system.dir}
HBase 
$ sudo -u hdfs hadoop fs -chown -R hbase ${hbase.rootdir}
蜂巢 
$ sudo -u hdfs hadoop fs -chown hive /user/hive
纱 
$ rm -rf ${yarn.nodemanager.local-dirs}/usercache/*

除了 YARN 之外，所有这些步骤都可能随时发生。YARN 的步骤必须在 Kerberos 安装之后发生，因为它正在做的是删除非 kerberized YARN 数据的用户缓存。当您在 Kerberos 安装后运行 mapreduce 时，它​​应该使用 Kerberized 用户缓存数据填充它。

YARN 用户缓存

YARN 应用程序以 exitCode 退出：-1000 无法初始化用户目录

KERBEROS 主要问题

  1) SHORT NAME RULES MAPPING

Kerberos 主体“映射”到操作系统级服务用户。例如，hdfs/WHATEVER@REALM 映射到您操作系统中的服务用户“hdfs”只是因为在 Hadoop 的核心站点中设置了名称映射规则。如果没有名称映射，Hadoop 将不知道哪个用户由哪个主体进行身份验证。

如果您使用的主体应映射到 hdfs，请确保主体名称根据这些 Hadoop 规则正确解析为 hdfs。

好的

（默认有名称映射规则）

  • hdfs@REALM
  • hdfs/_HOST@REALM
坏的

（默认无名称映射规则）

  • hdfs-TAG@REALM

除非您添加规则以适应它，否则“坏”示例将不起作用

名称规则映射

http://www.cloudera.com/documentation/archive/cdh/4-x/4-5-0/CDH4-Security-Guide/cdh4sg_topic_19.html )

  2) KEYTAB AND PRINCIPAL KEY VERSION NUMBERS MUST MATCH

密钥版本号 (KVNO) 是正在使用的密钥版本（就好像你有一把房子钥匙，但后来换了门锁，所以它使用了新钥匙，旧钥匙不再有用了） . keytab 和 principal 都有一个 KVNO，并且版本号必须匹配。

默认情况下，当您使用 ktadd 或 xst 将主体导出到 keytab 时，它会更改 keytab 版本号，但不会更改主体的 KVNO。因此，您最终可能会意外地造成不匹配。

-norandkey与kadmin或在将主体导出到密钥表时使用，kadmin.local以避免更新密钥表编号和创建 KVNO 不匹配。

通常，每当遇到主体问题时，请确保检查主体的 KVNO 和 keytab 是否匹配：

主要的 
$ kadmin.local -q 'getprinc myprincipalname'
密钥表 
$ klist -kte mykeytab
创建校长

http://www.cloudera.com/documentation/archive/cdh/4-x/4-3-0/CDH4-Security-Guide/cdh4sg_topic_3_4.html

安全罐和 JAVA 主页

  1) JAVA VERSION MISMATCH WITH JCE JARS

Hadoop 需要安装 Java 安全 JCE Unlimited Strength jar 才能将 AES-256 加密与 Kerberos 一起使用。Hadoop 和 Kerberos 都需要访问这些 jar。这是一个安装问题，但很容易错过，因为您可能认为您已经安装了安全 jar，而实际上您并没有。

要检查的 JCE 配置：
  • jar 是正确的版本 - 正确的安全 jar 与 Java 捆绑在一起，但如果您在安装它们之后必须确保 jar 的版本与 Java 的版本相对应，否则您将继续收到错误。要进行故障排除，请检查您正在使用的全新 JDK 下载中的 md5sum 哈希值与 Kerberos 服务器上的 md5sum 哈希值。
  • 罐子在正确的位置$JAVA_HOME/jre/lib/security
  • Hadoop 配置为在正确的位置查找它们。检查是否有导出语句用于$JAVA_HOME正确的 Java 安装位置/etc/hadoop/conf/hadoop-env.sh

如果 HadoopJAVA_HOME设置不正确，它将失败并显示“GSS INITIATE FAILED”。如果 jar 不在正确的位置，Kerberos 将找不到它们，并会给出一个错误，即它不支持 AES-256 加密类型 (UNSUPPORTED ENCTYPE)。

Cloudera 与 JCE 罐子

http://www.cloudera.com/documentation/enterprise/5-5-x/topics/cm_sg_s2_jce_policy.html

JCE jar 故障排除

https://community.cloudera.com/t5/Cloudera-Manager-Installation/Problem-with-Kerberos-amp-user-hdfs/td-p/6809

使用 JDK 6 和 MIT KERBEROS 1.8.1 及更高版本续订票证

Cloudera 在http://www.cloudera.com/documentation/archive/cdh/3-x/3u6/CDH3-Security-Guide/cdh3sg_topic_14_2.html中记录了一个问题，其中必须在发出 hadoop 命令之前更新票证。这只发生在 Oracle JDK 6 Update 26 或更早版本以及 MIT Kerberos 发行版的包版本 1.8.1 或更高版本中。

要检查软件包，请rpm -qa | grep krb5在 CentOS/RHEL 或aptitude search krb5 -F "%c %p %d %V"Debian/Ubuntu 上执行。

所以像你一样做一个常规的 kinit ，然后做一个kinit -R强制更新票证。

$ kinit -kt mykeytab myprincipal
$ kinit -R

最后，我实际遇到的问题在任何地方都找不到记录......

配置文件和票据缓存

Kerberos 有两个重要的配置文件，thekrb5.conf和 kdc.conf。这些是 krb5kdc 服务和 KDC 数据库的配置。我的问题是krb5.conf文件有一个属性： default_ccache_name = KEYRING:persistent:%{uid}.

这将我的缓存名称设置为 KEYRING:persistent 和用户 uid（解释为https://web.mit.edu/kerberos/krb5-1.13/doc/basic/ccache_def.html）。当我执行 kinit 时，它在 /tmp 中创建了票证，因为缓存名称在其他地方设置为 /tmp。Cloudera 服务使用运行时生成的文件在 /var/run/cloudera-scm-agent/process 中获取身份验证，并且这些都在执行其kinit. 这就是为什么 Cloudera 可以获得门票，但我的 hadoop 用户却不能。

解决方案是从 krb5.conf 中删除设置 default_ccache_name 并允许 kinit 将凭据存储在的行/tmp，这是 MIT Kerberos 默认值 DEFCCNAME（记录在https://web.mit.edu/kerberos/krb5-1.13/doc /mitK5defaults.html#paths）。

Cloudera 和 Kerberos 安装指南：

一步步

https://www.cloudera.com/documentation/enterprise/5-6-x/topics/cm_sg_intro_kerb.html。

高级故障排除

http://www.cloudera.com/documentation/enterprise/5-6-x/PDF/cloudera-security.pdf，从第 48 页开始。

于 2016-09-26T16:04:41.713 回答