大家好，我是明哥!

本片博文，分享下 HIVE 常見的三種 AUTHENTICATION 認證機制，包括其配置與使用。

1 數據安全概述

數據在企業中作為具有戰略意義的重要資產，其安全性受到了越來越高的重視，任何形式的誤刪除，誤修改，越權使用，不慎泄露等，都是重大的安全事件。為了保護數據安全，各企業都實施了嚴格的數據使用規范和準則，也應用了各種數據安全技術，確保數據的安全使用。

在技術層面，安全有個 3A+1E 的概念，3A+1E 涵蓋了安全的方方面面，3A 即 Authentication 認證，Authorization 鑒權，和Audit 審計;1 E 即 Encrption 加密：

• 其中 Authentication 解決的是身份認證的問題，通俗的來說就是驗明真身，證明用戶確實是他聲稱的身份而不是由由其它身份偽裝而來;
• Authorization 解決的是權限驗證問題，即執行某個具體操作前，確認該用戶確實有執行該操作的權限，而不是越權行事;
• Audit 解決的是審計問題，是在事后定期查看安全相關操作記錄，從而進一步調整安全策略的基礎;
• Encrption 解決的是加密與解密問題，分為靜態數據的加解密與數據傳輸過程中的加解密。通過加解密，數據即使被截獲了也不會造成安全事故。

針對某一個用戶的某一次數據操作來看，Authentication是事前的安全措施，Authorization 是事中的安全措施，Audit是事后的安全措施。三者聯動，才能確保真正的安全。這三者之中，Authentication是基礎，因為如果不能證明用戶身份，一切都無從談起;而Authorization 是核心和主題，也是具體業務系統實現時大家更關注的地方。

2 HIVE 的 AUTHENTICATION 認證機制概述

具體到大數據組件 Hive，其支持的客戶端的 authentication 認證機制，需要通過服務端參數 hive.server2.authentication 來配置，可配置的值有多種，見下圖官網截圖：

在實際應用中，大家經常使用的有以下三種：

• NONE：即不做身份校驗;
• LDAP: 使用基于 LDAP/AD 的用戶身份校驗;
• KERBEROS: 使用 Kerberos/GSSAPI 做身份校驗;

客戶端，不管是 beeline 等專用 cli 客戶端，還是 dbeaver 等通用 jdbc gui 客戶端，抑或 JAVA 應用(基于jdbc)，都需要根據服務端配置的認證方式，使用對應的方式，進行認證后才能成功連上 hiveserver2，進而提交查詢命令。

3 HIVE 常見的三種 AUTHENTICATION 認證機制的應用場景和配置方式

3.1 hive.server2.authentication = none

• 當不需要對用戶身份進行校驗，可以配置 hive.server2.authentication = none, 這種境況經常用在測試環境，生產環境一般不推薦;
• 此時用戶通過各種客戶端如 cli/gui/java 登錄時，可以不配置用戶名和密碼, 在服務端 Hive 會認為登錄的是匿名用戶 anonymous,如：如：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default
• 此時用戶通過各種客戶端如 cli/gui/java 登錄時，也可以配置為任意用戶名和任意密碼,在服務端 Hive 會認為登錄的是用戶聲明的任意用戶(用戶名可以是任意用戶名，甚至是不存在的用戶名;密碼可以是任意密碼，或不配置密碼)，如：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n xyz;beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n xyz -p xxxx

可以通過 hiveserver2 webui，驗證登錄的用戶身份;

3.2 hive.server2.authentication = ldap

• 中大型企業中一般都會有用戶身份的統一認證平臺，其底層一般都使用 ldap 協議，其具體實現有微軟的 ActiveDirectory， 也有 openLdap, ApacheDS等開源實現;
• Hive 提供了基于 Ldap 的認證機制，可以使用企業的統一認證平臺，來驗證登錄hive的用戶的身份,其配置方式：hive.server2.authentication = ldap;
• 具體的 ldap 工具的 url，需要通過參數指定：hive.server2.authentication.ldap.url;
• 除了集成商業版的 ActiveDirectory，大數據集群中也可以使用獨立安裝的開源的ldap工具，此類工具常見的有 openLdap 和 ApacheDS，其中前者在大部分linux發行版中都自帶了package安裝包，更容易安裝，不過主要通過命令行cli進行管理;而后者則自帶了gui客戶端 Apache Directory Studio，功能更為豐富;以 openLdap為例，其安裝命令如下：sudo yum -y install openldap-clients; sudo yum -y install openldap;
• 客戶端登錄 ldap 認證的 hiveserver2 時，需要提供用戶名和密碼，hiveserver2 會到ldap中驗證用戶名和密碼，只有驗證通過后才能正常登錄;

以 beeline 登錄為例，其命令格式如下：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n hs_cic -p xyzabc;

3.3 hive.server2.authentication = kerberos

• 大數據生態中，大部分組件都支持 kerberos 安全認證;
• 在開啟了 kerberos 安全認證的大數據集群環境中，需要交互的各個用戶/客戶端/服務端，都需要經過 kdc 的認證獲得了 ticket 憑證后，才能與其他組件進行正常交互，所以在大數據集群環境中，一旦基礎服務 hdfs/yarn/zookeeper 等開啟了 kerberos 安全認證，需要與 hdfs/yarn/zk 這些基礎組件交互的各個上層組件，如 hive/hbase/spark/flink 等，都需要配置使用相應的 kerberos principal，只有在經過 kdc 驗證獲得 ticket 后，才能與 hdfs/yarn/zk 進行交互;
• 具體到 hiveserver2，其在跟開啟了 kerberos 安全認證的 hdfs/yarn/hbase 等交互時，同樣需要配置使用相應的 kerberos principal(一般配置為hive)，且只有在經過 kdc 驗證獲得 ticket 后，才能與 hdfs/yarn/zk 進行交互,hive-site.xml中，相關配置項截圖如下：

• hiveserver2 本身，也可以配置使用 kerberos 認證機制，即要求 hiveserver2 的各種客戶端如 cli/gui/java jdbc，只有在通過 kerberos 認證獲得ticket 后，才能正常登陸 hiveserver2 進而提交 sql,其配置方式是：hive.server2.authentication = kerberos;

4 開啟了 kerberos 安全認證的大數據集群環境中，HIVE 的 kerberos/ldap 認證方式的配置方式和使用細節

• 在開啟了 kerberos 安全認證的大數據集群環境中，HIVE既可以配置使用 kerberos 認證機制，也可以配置使用 LDAP 認證機制;
• 其配置方式比較簡單，配置參數 hive.server2.authentication = kerberos/ldap 即可;
• 不過在使用方式上，有不少容易犯錯的細節，需要強調下。

4.1 kerberos 環境下，hive 的 kerberos 認證方式: hive.server2.authentication = kerberos

• 由于是在kerberos環境下，所以客戶端在登錄前，需要首先從 kdc 獲取 ticket 并維護在 ticket cache中：a valid Kerberos ticket in the ticket cache before connecting：
  • 如果是cli等客戶端，一般會通過命令 kinit principal_name -kt key_tab_location，基于 keytab 文件來獲取特定業務用戶的 ticket，并存儲在客戶端的 ticket cache中;(如果緩存的 ticket 過期了，需要通過命令重新獲取;如果不使用keytab, 也可以通過密碼來獲取 ticket: kinit principal_name);
  • 如果是程序代碼，則一般通過 org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(String user, String path) 的方式，基于keytab文件來獲取特定業務用戶的 ticket，并存儲在客戶端的 ticket cache中;(UserGroupInformation 在后臺會自動基于keytab 文件來定時刷新ticket，確保不會過期);
• 客戶端在獲取業務用戶的 ticket 成功后，才可以通過 jdbc連接，登錄到指定的 hiveserver2：
  • 此時需要特別注意下 hiveserver2 的url的格式，其格式推薦使用：jdbc:hive2://xx.xx.xx.xx:10000/default;principal=hive/[email protected]：
  • 這里的principal部分，推薦使用三段式來指定，包含pincipal, host 和 realm;
  • pincipal 必須指定為系統用戶hive，而不能是業務用戶如 dap,xyz等(本質上是因為，hive-site.xml 中配置的hive系統用戶是hive);
  • host部分，推薦指定為_HOST，此時在底層使用時會替換為 hiveserver2 節點的hostname (當然也可以直接指定為 hiveserver2 節點的具體的 hostname);
  • realm 部分，需要根據實際配置情況進行指定(可以查看配置文件 /etc/krb5.conf);

4.2 kerberos環境下，hive 的 LDAP 認證方式 : hive.server2.authentication = ldap

• 由于是在kerberos環境下，所以客戶端在登錄前，需要首先從 kdc 獲取 ticket 并維護在 ticket cache中，這一點跟 kerberos 環境下，hive 的 kerberos 認證方式時一直的：a valid Kerberos ticket in the ticket cache before connecting：
  • 如果是cli等客戶端，一般會通過命令 kinit principal_name -kt key_tab_location，基于 keytab 文件來獲取特定業務用戶的 ticket，并存儲在客戶端的 ticket cache中;(如果緩存的 ticket 過期了，需要通過命令重新獲取;如果不使用keytab, 也可以通過密碼來獲取 ticket: kinit principal_name);
  • 如果是程序代碼，則一般通過 org.apache.hadoop.security.UserGroupInformation.loginUserFromKeytab(String user, String path) 的方式，基于keytab文件來獲取特定業務用戶的 ticket，并存儲在客戶端的 ticket cache中;(UserGroupInformation 在后臺會自動基于keytab 文件來定時刷新ticket，確保不會過期);
• 客戶端在獲取業務用戶的 ticket 成功后，才可以通過 jdbc連接，登錄到指定的 hiveserver2，此時登錄格式，跟非 kerberos 環境下，hive 的 ldap認證方式，是一樣的：
  • 客戶端登錄 ldap 認證的 hiveserver2 時，需要提供用戶名和密碼，hiveserver2 會到ldap中驗證用戶名和密碼，只有驗證通過后才能正常登錄;
  • 以 beeline 登錄為例，其命令格式如下：beeline -u jdbc:hive2://xx.xx.xx.xx:10000/default -n hs_cic -p xyzabc;

5 大數據平臺 CDH/TDH/CDP 與 TDH 中， hive 認證方式的差異

• CDH/TDH/CDP中，在 CDH 5.7 及以后的版本中，Cloudera 對hive的安全認證進行了增強：在大數據集群開啟了 kerberos 安全認證的環境下，即使 hive 服務端配置了使用ldap (hive.server2.authentication = ldap)，客戶端也可以通過url指定使用 KERBEROS 認證方式來登錄;
• TDH 中，通過安全組件 Guardian 來管理各個組件的安全，Guardian 底層整合了 kerberos 和 ApacheDS，其推薦的hive認證方式，其實等同于 “kerberos環境下，hive 的 LDAP 認證方式 : hive.server2.authentication = ldap”;
• 在TDH環境下，在大數據集群開啟了 kerberos 安全認證的環境下，如果 hive 服務端配置了使用ldap (hive.server2.authentication = ldap)，則必須通過kerberos和ldap的雙重認證后，才能登陸 hiveserver2;

6 知識總結

• 數據安全在技術層面，有個 3A+1E 的概念：3A 即 Authentication 認證，Authorization 鑒權，和Audit 審計，1 E 即 Encrption 加密;
• 大數據組件 Hive，其支持的客戶端的 authentication 認證機制，需要通過服務端參數 hive.server2.authentication 來配置，可配置的值有多種，常見的有 NONE/LDAP/KERBEROS;
• Hive 的 Ldap 認證機制，可以使用企業的統一認證平臺，來驗證登錄 hive 的用戶的身份;
• 在大數據集群開啟了 kerberos 安全認證的環境下，hive 支持兩種認證方式：kerberos 和 ldap;
• 在大數據集群開啟了 kerberos 安全認證的環境下，需要交互的各個用戶/客戶端/服務端，都需要經過 kdc 的認證獲得了 ticket 憑證后，才能與其他組件進行正常交互，所以在大數據集群環境中，一旦基礎服務 hdfs/yarn/zookeeper 等開啟了 kerberos 安全認證，需要與 hdfs/yarn/zk 這些基礎組件交互的各個上層組件，如 hive/hbase/spark/flink 等，都需要配置使用相應的 kerberos principal，只有在經過 kdc 驗證獲得 ticket 后，才能與 hdfs/yarn/zk 進行交互;
• hiveserver2 在跟開啟了 kerberos 安全認證的 hdfs/yarn/hbase 等交互時，同樣需要配置使用相應的 kerberos principal(一般配置為hive)，且只有在經過 kdc 驗證獲得 ticket 后，才能與 hdfs/yarn/zk 進行交互;
• hiveserver2 本身，也可以配置使用 kerberos 認證機制，即要求 hiveserver2 的各種客戶端如 cli/gui/java jdbc，只有在通過 kerberos 認證獲得ticket 后，才能正常登陸 hiveserver2 進而提交 sql;
• 在大數據集群開啟了 kerberos 安全認證的環境下，hive 客戶端在登錄前，需要首先從 kdc 獲取業務用戶的 ticket 并維護在 ticket cache中, hive 客戶端只有在獲取業務用戶的 ticket 成功后，才可以通過 jdbc連接，登錄到指定的 hiveserver2;
• hiveserver2 在 kerberos 認證方式下，需要特別注意下 hiveserver2 的url的格式，其格式推薦使用：jdbc:hive2://xx.xx.xx.xx:10000/default;principal=hive/[email protected]：
• CDH/TDH/CDP中，在 CDH 5.7 及以后的版本中，Cloudera 對hive的安全認證進行了增強：在大數據集群開啟了 kerberos 安全認證的環境下，即使 hive 服務端配置了使用ldap (hive.server2.authentication = ldap)，客戶端也可以通過url指定使用 KERBEROS 認證方式來登錄;
• TDH 中，通過安全組件 Guardian 來管理各個組件的安全，Guardian 底層整合了 kerberos 和 ApacheDS，其推薦的hive認證方式，其實等同于 “kerberos環境下，hive 的 LDAP 認證方式 : hive.server2.authentication = ldap”;
• 在TDH環境下，在大數據集群開啟了 kerberos 安全認證的環境下，如果 hive 服務端配置了使用ldap (hive.server2.authentication = ldap)，則必須通過kerberos和ldap的雙重認證后，才能登陸 hiveserver2;

• hive-site.xml中，相關參數有：
  
  • hive.server2.authentication
  • hive.server2.authentication.kerberos.keytab
  • hive.server2.authentication.kerberos.principal
  • hive.server2.authentication.spnego.keytab
  • hive.server2.authentication.spnego.principal
  • hive.server2.authentication.ldap.url
  • hive.server2.authentication.ldap.baseDN
  • hive.server2.authentication.ldap.Domain
  • hive.server2.enable.doAs
  • hive.metastore.kerberos.keytab.file
  • hive.metastore.kerberos.principal

原文鏈接：https://mp.weixin.qq.com/s/Lv2SmtZ1Nj2fkDEMirFYiw