先借用几句话，不代表我个人看法
1.远离kerberos，珍爱生命，kerberos对hadoop来说是个大坑，阿里用了之后，马上放弃了。
2.kerberos对hadoop来说是个大坑？ 那阿里目前用什么做安全验证？
刚开始接到这个任务的时候，需求是这样描述的：
之前有个老HBase集群，现在准备迁移至新HBase集群，带了Kerberos，蛮简单的，加个认证就OK了，这周搞定（当时周四还是周五了都，而且需求方不在本地，最后还要远程让交付同事调试）
由于之前简单搜索过过一些关于Kerberos方面的问题，就很轻松的答应了...
根据网上各种Java连接带Kerberos的HBase集群方案，就几行代码嘛
//1.配置HBaseConfiguration的principal，user.keytab，krb5.conf：
HBaseConfiguration configuration = HBaseConfiuration.create();
configuration.set(xxx,xxx);
...
...
2.UserGroupInformation.setConfiguration(configuration);
3.UserGroupInformation.loginUserFromKeytab(principal, keytabFile);
嗯，就好了。
Too young, sometimes naive.
谁他妈家生产环境HBase的Kerberos只有这层啊？
神他妈只有HBase的配置需要改，还真的要初始化到HBaseConfiguration里，兄弟你家的是伪分布式单点的玩具HBase吧？
由于对接的是菊花厂，虽然个人不是很喜欢，但别人的确提供了一份样例代码以供参考
首先zk就加了Jaas验证...不配置zk的principal就直接gg，告诉你session expired
其次才是HBase的验证，我不是很确定HBaseConfiguration里面是不是真的需要修改principal和keytab，反正krb5.conf是不用改的，丢到System.properties里面就行。之前还让交付同事把HBase集群里面的hbase-site里面的principal和user.keytab完全复制了以后丢到Java这边的配置里，MDZZ啊。。。
远程了以后才发现我们应用被单独发了一个principal和user.keytab，还是看了封装的一个login.sh才发现pincipal的...哎，当时整个人都是懵逼的，赶紧把这个principal和keytab丢到配置里
后来把玩具代码发过去了，终于可以连上Kerberos的zk和HBase...
最后写点我个人的看法：
- Kerberos虽然安全，但这个安全是强加于KDC和client之间的互信，因为Kerberos是完全的A（KDC）和B（client）之间的互信，用principal替换了用户名，keytab替换了密码，krb5.conf替换了domain的感觉。如果C（任何第三方）可以获取B（client）的登录信息（如服务器用户名密码），就可以说都不用去仿造什么，直接拿着B的principal和keytab在任何地方搞事情（不排除有这种情况，但B的信息一旦泄露，gg）。
- 每个一段时间需要重新认证一次，当然也看到过把超时时间设成99999999d这种的..
- 安装配置有点复杂，现在还在自己搭一个完全的hadoop和zk+Kerberos+其他应用如HBase这种。。。。
- 后续继续补充吧，看生产环境接入还需要修改哪些内容...
