Hadoop安全機制介紹

1．背景

1.1 共享Hadoop集羣

當前大一點的公司都採用了共享Hadoop集羣的模式，這種模式能夠減少維護成本，且避免數據過分冗餘，增長硬件成本。共享Hadoop是指：（1）管理員把研發人員分紅若干個隊列，每一個隊列分配必定量的資源，每一個用戶或者用戶組只能使用某個隊列中得資源；（2）HDFS上存有各類數據，有公用的，有機密的，不一樣的用戶能夠訪問不一樣的數據。

共享集羣相似於雲計算或者雲存儲，面臨的一個最大問題是安全。

1.2 幾個概念

安全認證：確保某個用戶是本身聲稱的那個用戶。

安全受權：確保某個用戶只能作他容許的那些操做

User：Hadoop用戶，能夠提交做業，查看本身做業狀態，查看HDFS上的文件

Service：Hadoop中的服務組件，包括：namenode，jobtracker，tasktracker，datanode

1.3  Hadoop安全機制現狀

Hadoop 一直缺少安全機制，主要表如今如下幾個方面：

(1) User to Service

[1] Namenode或者jobtracker缺少安全認證機制

Client的用戶名和用戶組名由本身指定。

若是你不指定用戶名和用戶組，Hadoop會調用linux命令「whoami」獲取當前linux用戶名和用戶組，並添加到做業的user.name和group.name兩個屬性中，這樣，做業被提交到JobTracker後，JobTracker直接讀取這兩個屬性（不通過驗證），將該做業提交到對應隊列（用戶名/用戶組與隊列的對應關係由專門一個配置文件配置，詳細可參考fair scheduler或者capacity scheduler相關文檔）中。若是你能夠控制你提交做業的那臺client機器，你能夠以任何身份提交做業，進而偷偷使用本來屬於別人的資源。

好比：你在程序中使用如下代碼：

conf.set(「user.name」, root);

conf.ser(「group.name」, root);

即可以以root身份提交做業。

[2] DataNode缺少安全受權機制

用戶只要知道某個block的blockID，即可以繞過namenode直接從datanode上讀取該block；用戶能夠向任意datanode上寫block。

[3] JobTracker缺少安全受權機制

用戶能夠修改或者殺掉任意其餘用戶的做業；用戶能夠修改JobTracker的持久化狀態。

(2) Service to service安全認證

Datanode與TaskTracker缺少安全受權機制，這使得用戶能夠隨意啓動假的datanode和tasktracker，如：

你能夠直接到已經啓動的某個TaskTracker上啓動另一個tasktracker：

./hadoop-daemon.sh start datanode

（3）磁盤或者通訊鏈接沒有通過加密

2. Hadoop安全機制

爲了加強Hadoop的安全機制， 從2009年起， Apache專門抽出一個團隊，爲Hadoop增長安全認證和受權機制，至今爲止，已經可用。

Apache Hadoop 1.0.0版本和Cloudera CDH3以後的版本添加了安全機制，若是你將Hadoop升級到這兩個版本，可能會致使Hadoop的一些應用不可用。

Hadoop提供了兩種安全機制：Simple和Kerberos。Simple機制（默認狀況，Hadoop採用該機制）採用了SAAS協議。 也就是說，用戶提交做業時，你說你是XXX（在JobConf的user.name中說明），則在JobTracker端要進行覈實，包括兩部分覈實，一是你究竟是不是這我的，即經過檢查執行當前代碼的人與user.name中的用戶是否一致；而後檢查ACL（Access Control List）配置文件（由管理員配置），看你是否有提交做業的權限。一旦你經過驗證，會獲取HDFS或者mapreduce授予的delegation token（訪問不一樣模塊由不一樣的delegation token），以後的任何操做，好比訪問文件，均要檢查該token是否存在，且使用者跟以前註冊使用該token的人是否一致。

注意：下面絕大多數安全機制都是基於Kerberos實現的。

3. RPC安全機制

在Hadoop RP中添加了權限認證受權機制。當用戶調用RPC時，用戶的login name會經過RPC頭部傳遞給RPC，以後RPC使用Simple Authentication and Security Layer（SASL）肯定一個權限協議（支持Kerberos和DIGEST-MD5兩種），完成RPC受權。

具體參考：https://issues.apache.org/jira/browse/HADOOP-6419

4．HDFS安全機制

Client獲取namenode初始訪問認證（使用kerberos）後，會獲取一個delegation token，這個token能夠做爲接下來訪問HDFS或者提交做業的憑證。

一樣，爲了讀取某個文件，client首先要與namenode交互，獲取對應block的的block access token，而後到相應的datanode上讀取各個block，而datanode在初始啓動向namenode註冊時，已經提早獲取了這些token，當client要從TaskTracker上讀取block時，首先驗證token，經過後才容許讀取。

5. MapReduce安全機制

【Job Submission】

全部關於做業的提交或者做業運行狀態的追蹤均是採用帶有Kerberos認證的RPC實現的。受權用戶提交做業時，JobTracker會爲之生成一個delegation token，該token將被做爲job的一部分存儲到HDFS上並經過RPC分發給各個TaskTracker，一旦job運行結束，該token失效。

【Task】

用戶提交做業的每一個task均是以用戶身份啓動的，這樣，一個用戶的task便不能夠向TaskTracker或者其餘用戶的task發送操做系統信號，最其餘用戶形成干擾。這要求爲每一個用戶在全部TaskTracker上建一個帳號。

【shuffle】

當一個map task運行結束時，它要將計算結果告訴管理它的TaskTracker，以後每一個reduce task會經過HTTP向該TaskTracker請求本身要處理的那塊數據，Hadoop應該確保其餘用戶不能夠獲取map task的中間結果，其作法是：reduce task對「請求URL」和「當前時間」計算HMAC-SHA1值，並將該值做爲請求的一部分發動給TaskTracker，TaskTracker收到後會驗證該值的正確性。

6．WebUI安全機制

這一塊須要針對每一個用戶單獨配置。

7．高層服務的安全機制

你可能會在Hadoop之上使用Oozie，HBase，Cassandra等開源軟件，爲此，你須要在這幾個軟件的配置文件和Hadoop配置文件中添加權限，具體方法參考：https://ccp.cloudera.com/display/CDHDOC/CDH3+Security+Guide

8．總結

下面對Hadoop在安全方面的改動進行彙總：

（1） HDFS

命令行不變，WEB UI添加了權限管理

（2） MapReduce添加了ACL

包括：

管理員可在配置文件中配置容許訪問的user和group列表

用戶提交做業時，可知道哪些用戶或者用戶組能夠查看做業狀態，使用參數-D mapreduce.job.acl-view-job

用戶提交做業時，可知道哪些用戶或者用戶組能夠修改或者殺掉job，使用參數：-D mapreduce.job.acl-modify-job

（3）MapReduce系統目錄（即：mapred.system.dir，用戶在客戶端提交做業時，JobClient會將做業的job.jar，job.xml和job.split等信息拷貝到該目錄下）訪問權限改成700

（4）全部task以做業擁有者身份運行，而不是啓動TaskTracker的那個角色，這

使用了setuid程序（C語言實現）運行task。 【注】若是你以hadoop用啓動了Hadoop集羣，則TaskTracker上全部task均以hadoop用戶身份運行，這很容易使task之間相互干擾，而加了安全機制後，全部task以提交用戶的身份運行，如：用戶user1提交了做業，則它的全部task均以user1身份運行。

（5）Task對應的臨時目錄訪問權限改成700

（6）DistributedCache是安全的

DistribuedCache分別兩種，一種是shared，能夠被全部做業共享，而private的只能被該用戶的做業共享。

9．有用的資料

（1）Map and Reduce tasks should run as the user who submitted the job

（2）Security features for Map/Reduce

（包含一個pdf文件，裏面有關於Hadoop安全機制的詳細說明）

（3）Hadoop Security DesignJust Add Kerberos? Really?

（4）hadoop-security-preview

（5）hadoop-security indetails in hadoop summit 2010

（6） 安裝Hadoop Kerbores方法