Hadoop 安全機制認證---Kerberos
1. 背景
在Hadoop1.0.0或者CDH3 版本之前， hadoop并不存在安全認證一說。默認集群內所有的節點都是可靠的，值得信賴的。用戶與HDFS或者M/R進行交互時并不需要進行驗證。導致存在惡意用 戶偽裝成真正的用戶或者服務器入侵到hadoop集群上，惡意的提交作業，修改JobTracker狀態，篡改HDFS上的數據，偽裝成NameNode 或者TaskTracker接受任務等。 盡管在版本0.16以后， HDFS增加了文件和目錄的權限，但是并沒有強認證的保障，這些權限只能對偶然的數據丟失起保護作用。惡意的用戶可以輕易的偽裝成其他用戶來篡改權限，致 使權限設置形同虛設。不能夠對Hadoop集群起到安全保障。
在Hadoop1.0.0或者CDH3版本后，加入了Kerberos認證機制。使得集群中的節點就是它們所宣稱的，是信賴的。Kerberos可以將認 證的密鑰在集群部署時事先放到可靠的節點上。集群運行時，集群內的節點使用密鑰得到認證。只有被認證過節點才能正常使用。企圖冒充的節點由于沒有事先得到 的密鑰信息，無法與集群內部的節點通信。防止了惡意的使用或篡改Hadoop集群的問題，確保了Hadoop集群的可靠安全。
2. Hadoop 安全問題
2.1 用戶到服務器的認證問題
- NameNode，,JobTracker上沒有用戶認證
用戶可以偽裝成其他用戶入侵到一個HDFS 或者MapReduce集群上。
- DataNode上沒有認證
Datanode對讀入輸出并沒有認證。導致如果一些客戶端如果知道block的ID，就可以任意的訪問DataNode上block的數據
- JobTracker上沒有認證
可以任意的殺死或更改用戶的jobs，可以更改JobTracker的工作狀態
2.2 服務器到服務器的認證問題
- 沒有DataNode, TaskTracker的認證
用戶可以偽裝成datanode ,tasktracker，去接受JobTracker, Namenode的任務指派。
3. Kerberos能解決的Hadoop安全認證問題
kerberos實現的是機器級別的安全認證，也就是前面提到的服務到服務的認證問題。事先對集群中確定的機器由管理員手動添加到kerberos數據庫 中，在KDC上分別產生主機與各個節點的keytab(包含了host和對應節點的名字，還有他們之間的密鑰)，并將這些keytab分發到對應的節點 上。通過這些keytab文件，節點可以從KDC上獲得與目標節點通信的密鑰，進而被目標節點所認證，提供相應的服務，防止了被冒充的可能性。
- 解決服務器到服務器的認證
由于kerberos對集群里的所有機器都分發了keytab，相互之間使用密鑰進行通信，確保不會冒充服務器的情況。集群中的機器就是它們所宣稱的，是可靠的。
防止了用戶偽裝成Datanode，Tasktracker，去接受JobTracker，Namenode的任務指派。
- 解決client到服務器的認證
Kerberos對可信任的客戶端提供認證，確保他們可以執行作業的相關操作。防止用戶惡意冒充client提交作業的情況。
用戶無法偽裝成其他用戶入侵到一個HDFS 或者MapReduce集群上
用戶即使知道datanode的相關信息，也無法讀取HDFS上的數據
用戶無法發送對于作業的操作到JobTracker上
- 對用戶級別上的認證并沒有實現
無法控制用戶提交作業的操作。不能夠實現限制用戶提交作業的權限。不能控制哪些用戶可以提交該類型的作業，哪些用戶不能提交該類型的作業。這些由ACL模塊控制（參考）
4. Kerberos工作原理介紹
4.1 基本概念
Princal(安全個體)：被認證的個體，有一個名字和口令
KDC(key distribution center ) : 是一個網絡服務，提供ticket 和臨時會話密鑰
Ticket：一個記錄，客戶用它來向服務器證明自己的身份，包括客戶標識、會話密鑰、時間戳。
AS (Authentication Server)： 認證服務器
TSG(Ticket Granting Server)： 許可證服務器
4.2 kerberos 工作原理
4.2.1 Kerberos協議
Kerberos可以分為兩個部分：
- Client向KDC發送自己的身份信息，KDC從Ticket Granting Service得到TGT(ticket-granting ticket)， 并用協議開始前Client與KDC之間的密鑰將TGT加密回復給Client。此時只有真正的Client才能利用它與KDC之間的 密鑰將加密后的TGT解密，從而獲得TGT。（此過程避免了Client直接向KDC發送密碼，以求通過驗證的不安全方式）
- Client利用之前獲得的TGT向KDC請求其他Service的Ticket，從而通過其他Service的身份鑒別
4.3 Kerberos認證過程
Kerberos協議的重點在于第二部分（即認證過程）：
（1）Client將之前獲得TGT和要請求的服務信息(服務名等)發送給KDC，KDC中的Ticket Granting Service將為Client和Service之間生成一個Session Key用于Service對Client的身份鑒別。然后KDC將這個Session Key和用戶名，用戶地址（IP），服務名，有效期, 時間戳一起包裝成一個Ticket(這些信息最終用于Service對Client的身份鑒別)發 送給Service， 不過Kerberos協議并沒有直接將Ticket發送給Service，而是通過Client轉發給Service，所以有了第 二步。
（2）此時KDC將剛才的Ticket轉發給Client。由于這個Ticket是要給Service的，不能讓Client看到，所以KDC用協議開始 前KDC與Service之間的密鑰將Ticket加密后再發送給Client。同時為了讓Client和Service之間共享那個密鑰(KDC在第一 步為它們創建的Session Key)，KDC用Client與它之間的密鑰將Session Key加密隨加密的Ticket一起返回給Client。
（3）為了完成Ticket的傳遞，Client將剛才收到的Ticket轉發到Service. 由于Client不知道KDC與Service之間的 密鑰，所以它無法算改Ticket中的信息。同時Client將收到的Session Key解密出來，然后將自己的用戶名，用戶地址（IP）打包成Authenticator用Session Key加密也發送給Service。
（4）Service 收到Ticket后利用它與KDC之間的密鑰將Ticket中的信息解密出來，從而獲得Session Key和用戶名，用戶地址（IP），服務名，有效期。然后再用Session Key將Authenticator解密從而獲得用戶名，用戶地址（IP）將其與之前Ticket中解密出來的用戶名，用戶地址（IP）做比較從而驗證 Client的身份。
（5）如果Service有返回結果，將其返回給Client。
4.4 kerberos在Hadoop上的應用
Hadoop集群內部使用Kerberos進行認證
具體的執行過程可以舉例如下：
4.5 使用kerberos進行驗證的原因
- 可靠 Hadoop 本身并沒有認證功能和創建用戶組功能，使用依靠外圍的認證系統
- 高效 Kerberos使用對稱鑰匙操作，比SSL的公共密鑰快
- 操作簡單 用戶可以方便進行操作，不需要很復雜的指令。比如廢除一個用戶只需要從Kerbores的KDC數據庫中刪除即可。
5. 參考資料
（1）kerberos原理：http://idior.cnblogs.com/archive/2006/03/20/354027.html
（2）什么是kerberos：http://www.logicprobe.org/~octo/pres/pres_kerberos.pdf
（3）“Hadoop Security Design” Owen O’Malley, Kan Zhang, Sanjay Radia, Ram Marti, and Christopher Harrell