Kerberos概念
1.Kerberos用户
Kerberos的本质是维护一套自己的用户；或者说是核心用户映射，比如你的系统用户里面有hdfs，那么我将会在KDC中创建一套基于机器（假设我们有三台安装了CDH的机器分别为slave1，slave2，slave3)的核心用户，于是需要创建如下用户（对于Hadoop里面的用户，这个创建是由cloudera manager在开启Kerberos的时候自动来做的，否则需要手动在KDC中创建）
hdfs/slave1@BD.COM
hdfs/slave2@BD.COM
hdfs/slave3@BD.COM；
当时使用用
kinit hdfs/slave1@BD.COM来设置当前主体的时候（同时也是基于此用户向KDC获取TGT），当前用户也就具备了非Kerberos环境下的hdfs的相应的权限，可以通过hadoop fs -command 来操作hdfs。
比如开启了Kerberos之后，你在看cloudera manager启动HDFS的时候，就会发现其实它是用hdfs/machine-name@domain-name来启动程序；这个时候可能出现上面描述的异常，只要重新再生成一下主体的keytab文件即可。
2.Kerberos缓存
至于部分Cache Type支持collection，否则真是能够缓存当前主体信息；支持collection的有：DIR and API，KEYRING，KCM。默认的貌似是FILE，即keytab文件；所以默认情况下是不支持collection；到了kerberos5之后，会在配置文件中增加了显式声明：
default_ccache_name = KEYRING:persistent:%{uid}
这样采用的就是KEYRING的缓存模式了，之前测试的情况，如果把这行给注释掉，则无法cache多条主体，但是如果把这行打开则支持了多条主体；查看的指令是
klist -l
可以看到缓存的collection。klist以及klist -A都是现实当前主体的详细信息。但是只有Cache类型为DIR and API，KEYRING，KCM的时候，才可以在Cache中保存多个用户信息；否则只能看到当前用户的信息
可以看到缓存的collection。klist以及klist -A都是现实当前主体的详细信息。但是只有Cache类型为DIR and API，KEYRING，KCM的时候，才可以在Cache中保存多个用户信息；否则只能看到当前用户的信息
3. 关于Keytab
Keytab里面存放着用户和密码信息，可以通过kadmin→ktadd username来进行添加；kadmin必须要管理员权限（管理员会自动获取该用户的密码hash，在本地client的keytab文件中做添加）；如果没有管理员权限，但是知道用户名和密码，可以通过ktutil的shell，通过一下指令来进行添加。
1 addent -password -p username@ADS.IU.EDU -k 1 -e rc4-hmac（需要在下调提示下键入密码） 2 wkt username.keytab
或者直接在命令行添加：
1 ktutil -k username.keytab add -p username@ADS.IU.EDU -e arcfour-hmac-md5 -V 1
然后使用以下方式就可以实现无密码登录（keytab登录）。
kinit username -k -t keytabfile.keytab
启动Kerberos
首先创建cloudera的的管理用户cloudera-scm/admin@BD.COM；之后注意在/var/lib/kerberos/krb5kdc/kadm5.acl里面添加cloudera-scm/admin@BD.COM *（可以使用通配形式），例如：
*/admin@BD.COM *
但是我的测试如果是大通配，可能会有问题，比如：*@BD.COM *；启动集群将会失败。后来添加了“cloudera-scm/admin@BD.COM *”才启动成功。
关闭Kerberos
1. hdfs：
1) hadoop.security.authentication 设置为simple
2) hadoop.security.authorization 取消勾选
3) dfs.datanode.address 设置为 50010；否则会爆socket链接异常
4) dfs.datanode.http.address 设置为 50075；同上
2. hbase：
1) hbase.security.authentication 设置为simple
2) hbase.security.authorization 取消勾选
3) 进入到zooker-client中设置/hbase的权限为“world:anyone:cdrwa”
setAcl /hbase world:anyone:cdrwa
3. zookeeper
enableSecurity 取消勾选
4. HUE
删除实例中Kerberos Ticket Renewer（没懂，实际中也没有发现该项有用）
关于配置
/etc/krb5.con中的配置
[realms]
FAYSON.COM = {
kdc = ip-172-31-6-148.fayson.com
admin_server = ip-172-31-6-148.fayson.com
}
注意kdc以及admin_server对应的值服务器的机器名称，不要照搬写上去哦；
否则将会在使用kinit的时候报错：
kinit: Cannot contact any KDC for realm 'FAYSON.COM' while getting initial credentials
关于JCE
1. 是否安装了JCE
$JAVA_HOME/bin/jrunscript -e 'print (javax.crypto.Cipher.getMaxAllowedKeyLength("RC5") >= 256);'
如果返回true则说明OK；
其中，openJDK默认就是有安装JCE的；
打印（调试）Kerberos
在hadoop-env.sh或者直接在命令行中敲入：
export HADOOP_OPTS="-Djava.net.preferIPv4Stack=true -Dsun.security.krb5.debug=true ${HADOOP_OPTS}”
此时Kerberos就是出于debug状态；在使用hadoop指令的时候（比如hadoop fs -ls /）之后将会看到更加详细的信息；开启了Kerberos之后，如果执行hadoop指令发生异常，可以通过此开关来查看异常信息；
例如，如果是JCE的异常，错误信息中指明keyTpye=18，则说明是JCE问题，因为这个异常一般情况下是你的JCE的本地策略支持了ACE256；但是其实应该不支持；可能是本地的策略被覆盖；或者配置不正确；下载符合版本的JCE进行覆盖即可。
再比如，
如果信息只有：
Native config name: /etc/krb5.conf
Loaded from native config
>>>KinitOptions cache name is /tmp/krb5cc_993
而没有指明当前的主体信息则说明当前的主体为空，可能是之前执行了kdestroy指令
Kerberos异常信息处理
1. SASL异常
执行：hadoop fs -ls /爆出异常：
18/01/15 21:32:00 WARN 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: "slave1/10.1.108.65"; destination host is: "slave1":8020;
解决：这个异常可能原因是用户不对，比如在没有kerberos的环境下使用hdfs用户，那么你就需要在KDC中创建一个hdfs@BD.COMy用户，注意hdfs这个用户必须是在各个Kerberos终端都已经创建的Linux系统用户
2. 密码错误
+ kinit -c /opt/cm-5.12.1/run/cloudera-scm-agent/process/1780-hdfs-NAMENODE/krb5cc_993 -kt /opt/cm-5.12.1/run/cloudera-scm-agent/process/1780-hdfs-NAMENODE/hdfs.keytab hdfs/slave1@BD.COM kinit: Password incorrect while getting initial credentials
解决：总是这个爆异常信息；开始尝试了在root用户下kinit也不好用；后来发现碰到此类问题需要在cloudera manager页面的Administration→security（就是启动Kerberos的页面）→进入到Kerberos Credentials的tab页面；勾选有问题的主体（这里是hdfs/slave1@BD.COM），点击Regenerate Selected按钮即完美解决。
另外，还有种情况：
org.apache.hadoop.security.KerberosAuthException: Login failure for user: hdfs/slave1@BD.COM from keytab hdfs.keytab javax.security.auth.login.LoginException: Checksum failed
解决：用户hdfs/slave1@BD.COM是cloudera创建，并维护密码的；但是后来我修改了密码；需要同步一下新的密码，在Administration→Security→Kerberos Credentials，勾选hdfs/slave1@BD.COM，点击Regenerate Selected按钮，即可实现重新生成该用户的keytab信息（因为已经为cloudera制定了具有管理员权限的账号，所以可以获取任何kerberos用户的账号以及hash-密码信息）。
解决：用户hdfs/slave1@BD.COM是cloudera创建，并维护密码的；但是后来我修改了密码；需要同步一下新的密码，在Administration→Security→Kerberos Credentials，勾选hdfs/slave1@BD.COM，点击Regenerate Selected按钮，即可实现重新生成该用户的keytab信息（因为已经为cloudera制定了具有管理员权限的账号，所以可以获取任何kerberos用户的账号以及hash-密码信息）。
3. ktadd文件异常
ktadd -k hdfs@BD.COM
Unsupported key table format version number while adding key to keytab
解决：这是因为ktadd -k filepath username中的filepath指定的keytab文件是一个非法文件；我是使用touch指令创建的，所以没有好用。
Unsupported key table format version number while adding key to keytab
解决：这是因为ktadd -k filepath username中的filepath指定的keytab文件是一个非法文件；我是使用touch指令创建的，所以没有好用。
4. 权限不够
在kadmin的shell中敲入cpw username的时候爆出异常：
Operation requires ``change-password'' privilege while changing hdfs@BD.COM's key
解决：这是因为当前用户权限不够；切换为一个拥有“*”或者修改密码权限的用户。
解决：这是因为当前用户权限不够；切换为一个拥有“*”或者修改密码权限的用户。