開啟Hadoop安全認證之後的問題及解決方案簡述
這篇部落格主要記錄在開啟Hadoop安全認真之後的一些痛點和解決方案的概述。而非討論為什麼需要開啟Hadoop安全認證或者Hadoop安全機制架構和實現。
Linux，Kerberos，OpenLDAP使用者資訊的集中管理
Hadoop安全模組不儲存使用者和使用者組資訊，而是依賴Linux系統的使用者和使用者組。同時，在開啟安全認證模式之後，需要對映kerberos principle到Linux user account以及對映user account到user group。隨之而來的問題是如何統一管理使用者資訊。
可選方案：
- 管理使用者資訊在Linux，Kerberos和OpenLDAP依賴Linux的使用者資訊：No，需要重複管理所有Linux系統的使用者資訊
- 管理使用者資訊在Kerberos，Linux和OpenLDAP依賴Kerberos的使用者資訊：No，Kerberos不支援使用者組
- 管理使用者資訊在OpenLDAP，Linux和Kerberos依賴OpenLDAP的使用者資訊：Yes
- Linux 依賴OpenLDAP的使用者資訊：使用 PAM 整合 OpenLDAP 實現Linux 統一管理系統使用者 http://www.ibm.com/developerworks/cn/linux/1406_liulz_pamopenldap/
- Kerberos依賴OpenLDAP的使用者資訊：https://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_ldap.html
Apache Hive許可權管理
Hive背後有不同的data storage，如hdfs，hbase。如果不依賴於類似Apache Sentry的產品，需要依賴背後的data storage的ACL進行許可權管理，如使用者查詢hdfs-based hive table時，需要有對hdfs資料的read許可權。此時的痛點在於對Hive schema的管理，例如防止使用者誤刪或者修改table，view。解決這一問題，比較有效和易於理解的方式是使用Storage-System Based Authorization － https://cwiki.apache.org/confluence/display/Hive/HCatalog+Authorization。這個解決方案的limitation是在建立external table時，也需要對data storage有建立許可權（如hdfs的folder，hbase的table）。
Apache HBase許可權管理
問題：HBase開啟安全模式之後，需要Grant許可權給到特定User或User Group，無法實現grant某一個namespace給到所有使用者，如grant ALL, '@namespace1'.
解決方案：在建立Hadoop使用者時，為使用者新增預設組，如 hadoop-user。
客戶端Java安全訪問
在Windows下，需要使用java目錄下的kinit，而不是MIT kerberos。
客戶端Python安全訪問
Thrift相比於restful有更好的執行效率，大部分Hadoop元件都通過Thrift實現了資料訪問，如Hive和Hbase的Thrift server。如果要基於Python實現Thrift客戶端，難點在於Kerberos認證。Python下，kerberos的認證主要有如下兩種方案, 但是都不支援windows。
1) kerberos(python package) >> pure-sasl(python package) >> thrift (python package)
2) cyrus-sasl-*, saslwrapper, python-saslwrapper(Linux libs) >> sasl(python package) >> thrift-sasl(python package) >> thrift(python package)
另外一個問題是，當需要實現一些長時間執行的程式時（超過TGT的lifetime），需要額外實現renew TGT，並重新建立Thrift連線。