看完您若是還不明白 Kerberos 原理，算我輸！

時間 2019-11-08

標籤看完若是還不明白 kerberos 原理简体版

原文原文鏈接

系統環境html

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

擴展連接node

1、Kerberos概述

強大的身份驗證和創建用戶身份是 Hadoop 安全訪問的基礎。用戶須要可以可靠地「識別」本身，而後在整個 Hadoop 集羣中傳播該身份。完成此操做後，這些用戶能夠訪問資源（例如文件或目錄）或與集羣交互（如運行 MapReduce 做業）。除了用戶以外，Hadoop 集羣資源自己（例如主機和服務）須要相互進行身份驗證，以免潛在的惡意系統或守護程序「冒充」受信任的集羣組件來獲取數據訪問權限。git

Hadoop 使用 Kerberos 做爲用戶和服務的強身份驗證和身份傳播的基礎。Kerberos 是一種計算機網絡認證協議，它容許某實體在非安全網絡環境下通訊，向另外一個實體以一種安全的方式證實本身的身份。 Kerberos 是第三方認證機制，其中用戶和服務依賴於第三方（Kerberos 服務器）來對彼此進行身份驗證。 Kerberos服務器自己稱爲密鑰分發中心或 KDC。在較高的層面上，它有三個部分：github

它知道的用戶和服務（稱爲主體）及其各自的 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 的特殊文件，該文件包含資源主體的身份驗證憑據。oracle

Kerberos 服務器控制的主機，用戶和服務集稱爲領域。less

2、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 原理也頗有幫助：

3、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/admin@EXAMPLE.COM。在本實例中：

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	FQDN@EXAMPLE.COM	nn/node1.example.com@EXAMPLE.COM
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（驗證者）

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

4、票證生命週期

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

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

5、Kerberos主體名稱

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

主體名稱	說明
username@EXAMPLE.COM	用戶的主體
username/admin@EXAMPLE.COM	admin 主體，可用於管理 KDC 數據庫。
K/M@EXAMPLE.COM	主密鑰名稱主體。一個主密鑰名稱主體可與每一個主 KDC 關聯。
krbtgt/EXAMPLE.COM@EXAMPLE.COM	生成票證授予票證時使用的主體。
kadmin/host1.example.com@EXAMPLE.COM	容許使用 kadmind 訪問 KDC 的主 KDC 服務器的主體。
ambari-qa-xxx@EXAMPLE.COM	Ambari 用於執行服務「冒煙」檢查並運行警報健康檢查。
HTTP/host1.example.com@EXAMPLE.COM	用於訪問 Hadoop Web UI 時用到的 principal

6、注意事項

1. 時鐘同步

全部參與 Kerberos 驗證系統的主機都必須在指定的最長時間（稱爲時鐘相位差）內同步其內部時鐘。針對這一要求，須要進行另外一種 Kerberos 安全檢查。若是任意兩臺參與主機之間的時間誤差超過了時鐘相位差，則客戶機請求會被拒絕。

時鐘相位差的最大缺省值爲 300 秒（5 分鐘）。出於安全緣由，不要將時鐘相位差增大到超過 300 秒。

時鐘同步設置方法：點我

7、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個密鑰。