先借用幾句話裳凸，不代表我個人看法
1.遠離kerberos薄货，珍愛生命碌奉，kerberos對hadoop來說是個大坑短曾，阿里用了之后，馬上放棄了赐劣。
2.kerberos對hadoop來說是個大坑嫉拐？ 那阿里目前用什么做安全驗證？
剛開始接到這個任務的時候魁兼，需求是這樣描述的：
之前有個老HBase集群婉徘，現(xiàn)在準備遷移至新HBase集群，帶了Kerberos咐汞，蠻簡單的盖呼，加個認證就OK了，這周搞定（當時周四還是周五了都化撕，而且需求方不在本地几晤，最后還要遠程讓交付同事調(diào)試）
由于之前簡單搜索過過一些關于Kerberos方面的問題，就很輕松的答應了...
根據(jù)網(wǎng)上各種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.
誰他媽家生產(chǎn)環(huán)境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啊。碰煌。舒岸。
遠程了以后才發(fā)現(xiàn)我們應用被單獨發(fā)了一個principal和user.keytab，還是看了封裝的一個login.sh才發(fā)現(xiàn)pincipal的...哎芦圾，當時整個人都是懵逼的蛾派，趕緊把這個principal和keytab丟到配置里
后來把玩具代碼發(fā)過去了，終于可以連上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這種的..
- 安裝配置有點復雜瞪慧，現(xiàn)在還在自己搭一個完全的hadoop和zk+Kerberos+其他應用如HBase這種髓考。。弃酌。氨菇。
- 后續(xù)繼續(xù)補充吧，看生產(chǎn)環(huán)境接入還需要修改哪些內(nèi)容...
