看完您如果還不明白 Kerberos 原理，算我輸！

系統環境

• 操作系統：CentOS 6 或 CentOS 7
• JDK 版本：1.8.0_151
• Ambari 版本：2.6.1
• HDP 版本：2.6.4.0

擴展鏈接

• Kerberos原理--經典對話
• 基於ambari的Kerberos安裝配置
• Windows本地安裝配置Kerberos客戶端
• Kerberos應用
• 基於Ambari禁用Kerberos
• 基於Kerberos環境下，使用Java連接操作Hive
• 看完您如果還不明白 Kerberos 原理，算我輸！

一、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 文件系統。 由於該用戶已經通過了驗證（即，該用戶已經擁有票證授予票證），因此當其嘗試訪問文件時，NFS 客戶機系統將自動透明地從 KDC 獲取 NFS 服務的票證。

  例如，假定用戶 joe 在服務器 boston 上使用 rlogin。由於該用戶已經通過了驗證（即，該用戶已經擁有票證授予票證），所以在運行 rlogin 命令時，該用戶將自動透明地獲取票證。該用戶使用此票證可隨時遠程登錄到 boston，直到票證到期為止。如果 joe 要遠程登錄到計算機 denver，則需要按照步驟 1 獲取另一個票證。

• 客戶機將票證發送到服務器。

  使用 NFS 服務時，NFS 客戶機會自動透明地將 NFS 服務的票證發送到 NFS 服務器。

• 服務器允許此客戶機進行訪問。

從這些步驟來看，服務器似乎並未與 KDC 通信。但服務器實際上與 KDC 進行了通信，並向 KDC 注冊了其自身，正如第一台客戶機所執行的操作。為簡單起見，該部分已省略。

關於 Kerberos 更多的原理講解可參考以下鏈接，對理解 Kerberos 原理也很有幫助：

• https://www.zhihu.com/question/22177404/answer/492680179
• https://www.anquanke.com/post/id/171552#h2-2

三、Kerberos基本概念

1. Key Distribution Center, or KDC

在啟用Kerberos的環境中進行身份驗證的受信任源。

2. Kerberos KDC Server

作為密鑰分發中心（KDC）的計算機或服務器。

3. Kerberos Client

集群中針對KDC進行身份驗證的任何計算機。

4. KDC Admin Account

Ambari用於在KDC中創建主體並生成密鑰表的管理帳戶。

5. Principal

Kerberos principal（又稱為主體）用於在kerberos加密系統中標記一個唯一的身份。主體可以是用戶（如joe）或服務（如namenode或hive）。

根據約定，主體名稱分為三個部分：主名稱、實例和領域。例如，典型的Kerberos主體可以是joe/[e-mail]。在本實例中：

• 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。由於服務未使用密碼登錄以獲取其票證，因此其主體的身份驗證憑據存儲在keytab密鑰表文件中，該文件從Kerberos數據庫中提取並本地存儲在服務組件主機上具有服務主體的安全目錄中。比如NameNode組件在node1.example.com主機上，啟用kerberos之后，會自動生成nn.service.keytab文件，並存儲在/etc/security/keytabs目錄下，用戶所有者是hdfs:hadoop，權限為400，如圖所示：

ambari 和 hadoop service 的 principals 都存儲 Kerberos KDC 中，如下圖所示：

Principal和Keytab命名約定

	慣例	示例
Principals	$service_component_name/$[e-mail]	nn/[e-mail]
Keytabs	$service_component_abbreviation.service.keytab	/etc/security/keytabs/nn.service.keytab

請注意前面的示例中每個服務主體的主名稱。這些主要名稱（例如nn或hive）分別代表NameNode或Hive服務。每個主要名稱都附加了實例名稱，即運行它的主機的FQDN。此約定為在多個主機（如DataNodes和NodeManager）上運行的服務提供唯一的主體名稱。添加主機名用於區分，例如，來自DataNode A的請求與來自DataNode B的請求。這一點很重要，原因如下：

• 一個 DataNode 的受損 Kerberos 憑據不會自動導致所有 DataNode 的 Kerberos 憑據受損。
• 如果多個 DataNode 具有完全相同的主體並同時連接到 NameNode ，並且正在發送的 Kerberos 身份驗證器恰好具有相同的時間戳，則身份驗證將作為重播請求被拒絕。

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 進行身份驗證。

6. realms name

包含 KDC 和許多客戶端的 Kerberos 網絡，類似於域，俗稱為領域。

7. keytab

keytab 是包含 principals 和加密 principal key 的文件。

keytab 文件對於每個 host 是唯一的，因為 key 中包含 hostname 。keytab 文件用於不需要人工交互和保存純文本密碼，實現到 kerberos 上驗證一個主機上的 principal 。

因為服務器上可以訪問 keytab 文件即可以以 principal 的身份通過 kerberos 的認證，所以，keytab 文件應該被妥善保存，應該只有少數的用戶可以訪問。

8. ticket（票證）

ticket 是一種信息包，用於將用戶身份安全地傳遞到服務器或服務。一個票證僅對一台客戶機以及某台特定服務器上的一項特殊服務有效。票證包含以下內容：

• 服務的主體名稱
• 用戶的主體名稱
• 用戶主機的 IP 地址
• 時間標記
• 定義票證生命周期的值
• 會話密鑰的副本

所有此類數據都使用服務器的服務密鑰進行加密。頒發票證之后，可重用票證直到其到期為止。

9. credential（憑證）

是一種信息包，其中包含票證和匹配的會話密鑰。憑證使用發出請求的主體的密鑰進行加密。通常，KDC 會生成憑證以響應客戶機的票證請求。

10. authenticator（驗證者）

是服務器用於驗證客戶機用戶主體的信息。 驗證者包含用戶的主體名稱、時間標記和其他數據。 與票證不同，驗證者只能使用一次，通常在請求訪問服務時使用。 驗證者使用客戶機和服務器共享的會話密鑰進行加密。 通常，客戶機會創建驗證者，並將其與服務器或服務的票證一同發送，以便向服務器或服務進行驗證。

四、票證生命周期

每當主體獲取包括票證授予票證 (Ticket–Granting Ticket, TGT) 在內的票證時，可以通過 kinit 的 -l 選項指定的生命周期值，前提是使用 kinit 獲取票證。缺省情況下，kinit 使用最長生命周期值。kdc.conf 文件中指定的最長生命周期值 (max_life)。

可通過 kinit 的 -r 選項指定的可更新生命周期值，前提是使用 kinit 獲取或更新票證。kdc.conf 文件中指定的最長可更新生命周期值 (max_renewable_life)。

五、Kerberos主體名稱

每個票證都使用主體名稱進行標識。主體名稱可以標識用戶或服務。以下是一些主體名稱的示例：

主體名稱	說明
[e-mail]	用戶的主體
username/[e-mail]	admin 主體，可用於管理 KDC 數據庫。
K/[e-mail]	主密鑰名稱主體。一個主密鑰名稱主體可與每個 主 KDC 關聯。
krbtgt/[e-mail]	生成票證授予票證時使用的主體。
kadmin/[e-mail]	允許使用 kadmind 訪問 KDC 的主 KDC 服務器的主體。
[e-mail]	Ambari 用於執行服務“冒煙”檢查並運行警報健康檢查。
HTTP/[e-mail]	用於訪問 Hadoop Web UI 時用到的 principal

六、注意事項

1. 時鍾同步

所有參與 Kerberos 驗證系統的主機都必須在指定的最長時間（稱為時鍾相位差）內同步其內部時鍾。針對這一要求，需要進行另一種 Kerberos 安全檢查。如果任意兩台參與主機之間的時間偏差超過了時鍾相位差，則客戶機請求會被拒絕。

時鍾相位差的最大缺省值為 300 秒（5 分鍾）。出於安全原因，不要將時鍾相位差增大到超過 300 秒。

時鍾同步設置方法：點我

七、Kerberos的優點和不足

1. 優點

較高的Performance

雖然我們一再地說Kerberos是一個涉及到3方的認證過程：Client、Server、KDC。但是一旦Client獲得用過訪問某個Server的Ticket，該Server就能根據這個Ticket實現對Client的驗證，而無須KDC的再次參與。和傳統的基於Windows NT 4.0的每個完全依賴Trusted Third Party的NTLM比較，具有較大的性能提升。

實現了雙向驗證（Mutual Authentication）

傳統的NTLM認證基於這樣一個前提：Client訪問的遠程的Service是可信的、無需對於進行驗證，所以NTLM不曾提供雙向驗證的功能。這顯然有點理想主義，為此Kerberos彌補了這個不足：Client在訪問Server的資源之前，可以要求對Server的身份執行認證。

對Delegation的支持

Impersonation和Delegation是一個分布式環境中兩個重要的功能。Impersonation允許Server在本地使用Logon 的Account執行某些操作，Delegation需用Server將logon的Account帶入到另過一個Context執行相應的操作。NTLM僅對Impersonation提供支持，而Kerberos通過一種雙向的、可傳遞的（Mutual 、Transitive）信任模式實現了對Delegation的支持。

互操作性（Interoperability）

Kerberos最初由MIT首創，現在已經成為一行被廣泛接受的標准。所以對於不同的平台可以進行廣泛的互操作。

2. 不足

• Kerberos身份認證采用的是對稱加密機制，加密和解密使用的是相同的密鑰，交換密鑰時的安全性比較難以保障。

• Kerberos服務器與用戶共享的服務會話密鑰是用戶的口令字，服務器在響應時不需驗證用戶的真實性，而是直接假設只有合法用戶擁有了該口令字。如果攻擊者截獲了響應消息，就很容易形成密碼攻擊。

• Kerberos中的AS（身份認證服務）和TGS是集中式管理，容易形成瓶頸，系統的性能和安全也嚴重依賴於AS和TGS的性能和安全。在AS和TGS前應該有訪問控制，以增強AS和TGS的安全。

• 隨用戶數量增加，密鑰管理較復雜。Kerberos擁有每個用戶的口令字的散列值，AS與TGS負責戶間通信密鑰的分配。假設有n個用戶想同時通信，則需要維護n×（n-1）/2個密鑰。

八、總結

本篇文章主要從Kerberos概述、驗證過程的描述、基本概念的解釋、Kerberos注意事項及優缺點的方面來介紹Kerberos的，接下來會出一個如何在Kerberos環境下使用Hadoop服務的文章教程，讓我們一起期待吧，哈哈

擴展鏈接

• Kerberos原理--經典對話
• 基於ambari的Kerberos安裝配置
• Windows本地安裝配置Kerberos客戶端
• Kerberos應用
• 基於Ambari禁用Kerberos
• 基於Kerberos環境下，使用Java連接操作Hive
• 看完您如果還不明白 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

---