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

阿新 • • 發佈：2019-10-04

作業系統：CentOS 6 或 CentOS 7
JDK 版本：1.8.0_151
Ambari 版本：2.6.1
HDP 版本：2.6.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 檔案系統。由於該使用者已經通過了驗證（即，該使用者已經擁有票證授予票證），因此當其嘗試訪問檔案時，NFS 客戶機系統將自動透明地從 KDC 獲取 NFS 服務的票證。

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

使用 NFS 服務時，NFS 客戶機會自動透明地將 NFS 服務的票證傳送到 NFS 伺服器。
伺服器允許此客戶機進行訪問。

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

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

三、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/[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。由於服務未使用密碼登入以獲取其票證，因此其主體的身份驗證憑據儲存在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/[email protected]	nn/[email protected]
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主體名稱

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

主體名稱	說明
[email protected]	使用者的主體
username/[email protected]	admin 主體，可用於管理 KDC 資料庫。
K/[email protected]	主金鑰名稱主體。一個主金鑰名稱主體可與每個<br />主 KDC 關聯。
krbtgt/[email protected]	生成票證授予票證時使用的主體。
kadmin/[email protected]	允許使用 kadmind 訪問 KDC 的主 KDC 伺服器的主體。
[email protected]	Ambari 用於執行服務“冒煙”檢查並執行警報健康檢查。
HTTP/[email protected]	用於訪問 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服務的文章教程，讓我們一起期待吧，哈哈