目錄
系統環境
-
操作系統： CentOS 7
-
JDK 版本：1.8.0_251
-
Ambari 版本：2.7.4
-
HDP 版本：3.1.4.0
擴展鏈接
一、Kerberos概述
強大的身份驗證和建立用戶身份是 Hadoop 安全訪問的基礎。用戶需要能夠可靠地 “識別” 自己，然後在整個 Hadoop 集羣中傳播該身份。完成此操作後，這些用戶可以訪問資源（例如文件或目錄）或與集羣交互（如運行 MapReduce 作業）。除了用戶之外，Hadoop 集羣資源本身（例如主機和服務）需要相互進行身份驗證，以避免潛在的惡意系統或守護程序 “冒充” 受信任的集羣組件來獲取數據訪問權限。
Hadoop 使用 Kerberos 作爲用戶和服務的強身份驗證和身份傳播的基礎。Kerberos 是一種計算機網絡認證協議，它允許某實體在非安全網絡環境下通信，向另一個實體以一種安全的方式證明自己的身份。 Kerberos 是第三方認證機制，其中用戶和服務依賴於第三方（Kerberos 服務器）來對彼此進行身份驗證。Kerberos服務器本身稱爲密鑰分發中心或 KDC。在較高的層面上，它有三個部分：
-
它知道的用戶和服務（稱爲主體）及其各自的 Kerberos 密碼的數據庫。
-
一個認證服務器（Authentication Server，簡稱 AS）：驗證Client端的身份（確定你是身份證上的本人），驗證通過就會給一張票證授予票證（Ticket Granting Ticket，簡稱 TGT）給 Client。
-
一個票據授權服務器（Ticket Granting Server，簡稱 TGS）：通過 TGT（AS 發送給 Client 的票）獲取訪問 Server 端的票（Server Ticket，簡稱 ST）。ST（Service Ticket）也有資料稱爲 TGS Ticket。
以平時坐火車舉例：
一個用戶主要來自AS請求認證。AS 返回 使用用戶主體 的 Kerberos密碼加密 的 TGT ，該密碼僅爲用戶主體和 AS 所知。用戶主體使用其 Kerberos 密碼在本地解密TGT，從那時起，直到ticket 到期，用戶主體可以使用 TGT 從 TGS 獲取服務票據。服務票證允許委託人訪問服務。
- Kerberos 簡單來說就是一個用於安全認證第三方協議，它採用了傳統的共享密鑰的方式，實現了在網絡環境不一定保證安全的環境下，client 和 server 之間的通信，適用於 client/server 模型，由 MIT 開發和實現。
- Kerberos 服務是單點登錄系統，這意味着您對於每個會話只需向服務進行一次自我驗證，即可自動保護該會話過程中所有後續事務的安全。
由於每次解密 TGT 時羣集資源（主機或服務）都無法提供密碼，因此它們使用稱爲 keytab 的特殊文件，該文件包含資源主體的身份驗證憑據。
Kerberos 服務器控制的主機，用戶和服務集稱爲領域。
二、Kerberos驗證過程
Kerberos 驗證分爲兩個階段：允許進行後續驗證的初始驗證以及所有後續驗證自身。
1、初始驗證：票證授予票證
下圖顯示瞭如何進行初始驗證：
-
客戶端通過從密鑰分發中心(Key Distribution Center, KDC)請求票證授予票證(Ticket-Granting Ticket, TGT)開始 Kerberos 會話。此請求通常在登錄時自動完成。
要獲取特定服務的其他票證，需要 TGT 。票證授予票證類似於護照。與護照一樣，TGT 可標識您的身份並允許您獲取多個“簽證”，此處的“簽證”（票證）不是用於外國，而是用於遠程計算機或網絡服務。與護照和簽證一樣，票證授予票證和其他各種票證具有有限的生命週期。區別在於基於 Kerberos 的命令會通知您擁有護照併爲您取得簽證。您不必親自執行該事務。
與票證授予票證類似的另一種情況是可以在四個不同的滑雪場使用的三天滑雪入場卷。只要入場券未到期，您就可以在決定要去的任意一個滑雪場出示入場卷，並獲取該滑雪場提供的纜車票。獲取纜車票後，即可在該滑雪場隨意滑雪。如果第二天去另一個滑雪場，您需要再次出示入場卷，並獲取新滑雪場的另一張纜車票。區別在於基於 Kerberos 的命令會通知您擁有周末滑雪入場卷，並會爲您取得纜車票。因此，您不必親自執行該事務。
-
KDC 可創建 TGT ，並採用加密形式將其發送回客戶端。客戶端使用其口令來解密 TGT 。
-
擁有有效的 TGT，只要該 TGT 未到期，客戶機便可以請求所有類型的網絡操作（如 rlogin 或 telnet）的票證。此票證的有效期通常爲一天。每次客戶端執行唯一的網絡操作時，都將從 KDC 請求該操作的票證。
2、後續Kerberos驗證
客戶機收到初始驗證後，每個後續驗證都按下圖所示的模式進行。
-
客戶機通過向 KDC 發送其 TGT 作爲其身份證明，從 KDC 請求特定服務（例如，遠程登錄到另一臺計算機）的票證。
-
KDC 將該特定服務的票證發送到客戶機。
例如，假定用戶
joe要訪問已通過要求的krb5驗證共享的 NFS 文件系統。由於該用戶已經通過了驗證（即，該用戶已經擁有票證授予票證TGT），因此當其嘗試訪問文件時，NFS 客戶機系統將自動透明地從 KDC 獲取 NFS 服務的票證。 -
客戶機將票證發送到服務器。
使用 NFS 服務時，NFS 客戶機會自動透明地將 NFS 服務的票證發送到 NFS 服務器。
-
服務器允許此客戶機進行訪問。
從這些步驟來看，服務器似乎並未與 KDC 通信。但服務器實際上與 KDC 進行了通信，並向 KDC 註冊了其自身，正如第一臺客戶機所執行的操作。爲簡單起見，該部分已省略。
三、Kerberos基本概念
- Key Distribution Center, or KDC
在啓用Kerberos的環境中進行身份驗證的受信任源。
- Kerberos KDC Server
作爲密鑰分發中心（KDC）的計算機或服務器。
- Kerberos Client
集羣中針對KDC進行身份驗證的任何計算機。
- KDC Admin Account
Ambari用於在KDC中創建主體並生成密鑰表的管理帳戶。
- credential（憑證）
是一種信息包，其中包含票證和匹配的會話密鑰。憑證使用發出請求的主體的密鑰進行加密。通常，KDC 會生成憑證以響應客戶機的票證請求。
- realms name
包含 KDC 和許多客戶端的 Kerberos 網絡，類似於域，俗稱爲領域。
1、Principal
Kerberos principal（又稱爲主體）用於在kerberos加密系統中標記一個唯一的身份。主體可以是用戶（如joe）或服務（如namenode或hive）。
根據約定，主體名稱分爲三個部分：主名稱、實例和領域。例如，典型的Kerberos主體可以是joe/[email protected]。在本實例中：
-
joe是主名稱。主名稱可以是此處所示的用戶名或namenode等服務。 -
admin是實例。對於用戶主體，實例是可選的；但對於服務主體，實例則是必需的。例如，如果用戶joe有時充當系統管理員，則他可以使用joe/admin將其自身與平時的用戶身份區分開來。同樣，如果joe在兩臺不同的主機上擁有帳戶，則他可以使用兩個具有不同實例的主體名稱，例如joe/node1.example.com和joe/node2.example.com。請注意，Kerberos 服務會將joe和joe/admin視爲兩個完全不同的主體。對於服務主體，實例是全限定主機名。例如，
node1.example.com就是這種實例。 -
EXAMPLE.COM是Kerberos領域。領域將在下一小節中介紹。
Hadoop中的每個服務和子服務都必須有自己的主體。給定領域中的 主體名稱 由 主名稱和實例名稱組成，在這種情況下，實例名稱是運行該服務的主機的FQDN（Fully Qualified Domain Name）。由於服務未使用密碼登錄以獲取其票證，因此其主體的身份驗證憑據存儲在keytab密鑰表文件中，該文件從Kerberos數據庫中提取並本地存儲在服務組件主機上具有服務主體的安全目錄中。比如NameNode組件在node1.example.com主機上，啓用kerberos之後，會自動生成nn.service.keytab文件，並存儲在/etc/security/keytabs目錄下，用戶所有者是hdfs:hadoop，權限爲400，如圖所示：
ambari 和 hadoop service 的 principals 都存儲 Kerberos KDC 中，如下圖所示：
2、Principal和Keytab命名約定
| 慣例 | 示例 | |
|---|---|---|
| Principals | $service_component_nam/[email protected] | nn/[email protected] |
| Keytabs | $service_component_abbreviation.service.keytab | /etc/security/keytabs/nn.service.keytab |
一個 DataNode 的受損 Kerberos 憑據不會自動導致所有 DataNode 的 Kerberos 憑據受損。請注意前面的示例中每個服務主體的主名稱。這些主要名稱（例如 nn 或 hive ）分別代表 NameNode 或 Hive 服務。每個主要名稱都附加了實例名稱，即運行它的主機的 FQDN。此約定爲在多個主機（如DataNodes和NodeManager）上運行的服務提供唯一的主體名稱。添加主機名用於區分，例如，來自 DataNode A 的請求與來自 DataNode B 的請求。這一點很重要，原因如下：
-
如果多個 DataNode 具有完全相同的主體並同時連接到 NameNode ，並且正在發送的 Kerberos 身份驗證器恰好具有相同的時間戳，則身份驗證將作爲重播請求被拒絕。
3、Ambari Principals
除了 Hadoop 服務主體之外，Ambari 本身還需要一組 Ambari Principal 來執行服務“冒煙”檢查，執行警報運行狀況檢查以及從集羣組件檢索指標。Ambari Principals 的 Keytab 文件駐留在每個羣集主機上，就像服務主體的 keytab 文件一樣。
| Ambari Principals | 描述 |
|---|---|
| Smoke and “Headless” Service users | Ambari 用於執行服務“冒煙”檢查並運行警報健康檢查。 |
| Ambari Server user | 爲 Kerberos 啓用集羣時，組件 REST 端點（例如 YARN ATS 組件）需要 SPNEGO 身份驗證。Ambari Server 需要訪問這些 API 並需要Kerberos主體才能通過 SPNEGO 針對這些 API 進行身份驗證。 |
4、keytab
keytab 是包含 principals 和加密 principal key 的文件。
keytab 文件對於每個 host 是唯一的，因爲 key 中包含 hostname 。keytab 文件用於不需要人工交互和保存純文本密碼，實現到 kerberos 上驗證一個主機上的 principal 。
因爲服務器上可以訪問 keytab 文件即可以以 principal 的身份通過 kerberos 的認證，所以，keytab 文件應該被妥善保存，應該只有少數的用戶可以訪問。
5、ticket（票證）
ticket 是一種信息包，用於將用戶身份安全地傳遞到服務器或服務。一個票證僅對一臺客戶機以及某臺特定服務器上的一項特殊服務有效。票證包含以下內容：
-
服務的主體名稱
-
用戶的主體名稱
-
用戶主機的 IP 地址
-
時間標記
-
定義票證生命週期的值
-
會話密鑰的副本
所有此類數據都使用服務器的服務密鑰進行加密。頒發票證之後，可重用票證直到期爲止。
6、 authenticator（驗證者）
是服務器用於驗證客戶機用戶主體的信息。驗證者包含用戶的主體名稱、時間標記和其他數據。與票證不同，驗證者只能使用一次，通常在請求訪問服務時使用。驗證者使用客戶機和服務器共享的會話密鑰進行加密。通常，客戶機會創建驗證者，並將其與服務器或服務的票證一同發送，以便向服務器或服務進行驗證。
四、票證生命週期
每當主體獲取包括票證授予票證 (Ticket–Granting Ticket, TGT) 在內的票證時，可以通過 kinit 的-l 選項指定的生命週期值，前提是使用 kinit 獲取票證。缺省情況下，kinit 使用最長生命週期值。kdc.conf 文件中指定的最長生命週期值 (max_life)。
可通過 kinit 的 -r 選項指定的可更新生命週期值，前提是使用 kinit 獲取或更新票證。kdc.conf 文件中指定的最長可更新生命週期值 (max_renewable_life)。
五、Kerberos主體名稱
每個票證都使用主體名稱進行標識。主體名稱可以標識用戶或服務。以下是一些主體名稱的示例：
| 主體名稱 | 說明 |
|---|---|
| [email protected] | 用戶的主體 |
| username/[email protected] | admin 主體，可用於管理 KDC 數據庫。 |
| K/[email protected] | 主密鑰名稱主體。一個主密鑰名稱主體可與每個 主 KDC 關聯。 |
| krbtgt/[email protected] | 生成票證授予票證時使用的主體。 |
| kadmin/[email protected] | 允許使用 kadmind 訪問 KDC 的主 KDC 服務器的主體。 |
| [email protected] | Ambari 用於執行服務“冒煙”檢查並運行警報健康檢查。 |
| HTTP/[email protected] | 用於訪問 Hadoop Web UI 時用到的 principal |
六、總結
本篇文章主要從 Kerberos 概述、驗證過程的描述、基本概念的解釋的方面來介紹 Kerberos 的。更多的 Kerberos 相關資料，可參考以下鏈接，建議都點開看看！
擴展鏈接
參考資料
-
https://docs.oracle.com/cd/E19253-01/819-7061/6n91j2vak/index.html（推薦閱讀）
-
https://www.zhihu.com/question/22177404/answer/492680179（推薦閱讀）
-
https://www.anquanke.com/post/id/171552#h2-2（推薦閱讀）
-
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.4/bk_security/content/kerberos_principals.html
-
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.5/bk_security/content/setting_up_kerberos_authentication_for_non_ambari_clusters.html