hadoop之启用安全性后，运行任何Hadoop命令都会失败。

我试图为 CDH 4.3 (通过Cloudera Manager)测试平台启用Kerberos。因此，在WebUI中将身份验证从“简单”更改为Kerberos后，我无法执行任何hadoop操作，如下所示。无论如何，有没有明确指定keytab？

[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]# 

以及 Realm 中的负责人列表。

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的密钥表，并用于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 

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

谢谢你，

请您参考如下方法:

我遇到了一个问题，其中我拥有一个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; DR

确保您有一张票

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

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

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

http://www.roguelynn.com/words/explain-like-im-5-kerberos/

有关Kerberos的其他一般故障排除，请查看https://steveloughran.gitbooks.io/kerberos_and_hadoop/content/sections/errors.html

CDH缺省HDFS用户和组限制

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

有几个属性可以处理此问题，包括将hdfs的超组设置为字符串 supergroup而不是 hdfs，默认情况下将 dfs_permissions enabled属性设置为 false( hadoop user file permissions)，禁止uid超过1000的用户。

这些因素中的任何一个都是可能的，对我而言，是HDFS列在banned.users属性中。

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

  1) UNPRIVILEGED USER AND WRITE PERMISSIONS 

Cloudera建议的执行Hadoop命令的方法是创建非特权用户和匹配的主体，而不是使用hdfs用户。需要注意的是，该用户还需要自己的 /user目录，并且可能会在/ user目录中遇到写权限错误。如果您的非特权用户在 /user中没有目录，则可能会导致“写入权限被拒绝”错误。

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。如果设置了错误的目录权限，则Kerberos安装将失败。数据节点的端口还必须设置为1024以下的值，对于HTTP端口，建议将其设置为1006，对于数据节点端口，建议将其设置为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服务进行内核化。确保您做了这些!

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之后进行，因为它正在执行的操作是删除非Kerberos化YARN数据的用户缓存。在安装Kerberos之后运行mapreduce时，应使用以Kerberized用户缓存的数据填充。

YARN用户缓存

YARN Application exited with exitCode: -1000 Not able to initialize user directories

KERBEROS主要问题

  1) SHORT NAME RULES MAPPING 

Kerberos主体被“映射”到OS级服务用户。例如，仅因为在Hadoop核心站点中设置了名称映射规则，hdfs / WHATEVER @ REALM才在操作系统中映射到服务用户“hdfs”。如果没有名称映射，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)是正在积极使用的密钥的版本(就像您有房门 key ，然后又改变了门上的锁，以便使用新的密钥一样，旧的密钥就不再有用了) 。密钥表和主体均具有KVNO，并且版本号必须匹配。

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

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

通常，每当主体存在身份验证问题时，请确保检查主体和密钥表的KVNO是否匹配:

校长

$ kadmin.local -q 'getprinc myprincipalname' 

Keytab

$ klist -kte mykeytab 

创建负责人

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

安全的JARS和JAVA主页

  1) JAVA VERSION MISMATCH WITH JCE JARS 

Hadoop需要安装Java安全性JCE无限强度jar才能使用Kerberos的AES-256加密。 Hadoop和Kerberos都需要有权访问这些jar。这是一个安装问题，但很容易遗漏，因为您可以认为实际上没有安装安全 jar 。

要检查的JCE配置:

这些 jar 是正确的版本-正确的安全 jar 与Java bundle 在一起，但是如果事后安装它们，则必须确保 jar 的版本与Java的版本相对应，否则您将继续出错。要进行故障排除，请针对Kerberos服务器上使用的JDK的全新下载中的md5sum散列检查md5sum散列。

jar 放在正确的位置$JAVA_HOME/jre/lib/security

Hadoop配置为在正确的位置查找它们。检查$JAVA_HOME中是否存在将/etc/hadoop/conf/hadoop-env.sh导出到正确的Java安装位置的语句

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

使用JCE Jars的Cloudera

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

对JCE Jars进行故障排除

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或更高版本中发生。

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

因此，请像执行常规的kinit一样，然后执行 kinit -R强制更新票证。

$ kinit -kt mykeytab myprincipal 
$ kinit -R 

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

配置文件和票务指导

Kerberos有两个重要的配置文件， krb5.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之前均会导出缓存名称环境变量(KRB5CCNAME)。这就是为什么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页开​​始。