日前筆者在使用flume采集數(shù)據(jù)直接入到Hadoop平臺(tái)HDFS上時(shí)，由于Hadoop平臺(tái)采用了Kerberos認(rèn)證機(jī)制。flume配置上是致辭kerberos認(rèn)證的，但由于flume要采集的節(jié)點(diǎn)并不在集群內(nèi)，所以需要學(xué)習(xí)Kerberos在Hadoop上的應(yīng)用。

1、Kerberos協(xié)議

Kerberos協(xié)議：

Kerberos協(xié)議主要用于計(jì)算機(jī)網(wǎng)絡(luò)的身份鑒別(Authentication),?其特點(diǎn)是用戶只需輸入一次身份驗(yàn)證信息就可以憑借此驗(yàn)證獲得的票據(jù)(ticket-granting ticket)訪問多個(gè)服務(wù)，即SSO(Single Sign On)。由于在每個(gè)Client和Service之間建立了共享密鑰，使得該協(xié)議具有相當(dāng)?shù)陌踩浴?br />
條件

先來看看Kerberos協(xié)議的前提條件：

如下圖所示，Client與KDC，?KDC與Service?在協(xié)議工作前已經(jīng)有了各自的共享密鑰，并且由于協(xié)議中的消息無法穿透防火墻，這些條件就限制了Kerberos協(xié)議往往用于一個(gè)組織的內(nèi)部，?使其應(yīng)用場(chǎng)景不同于X.509 PKI。

?

過程

Kerberos協(xié)議分為兩個(gè)部分：

1 . Client向KDC發(fā)送自己的身份信息，KDC從Ticket Granting Service得到TGT(ticket-granting ticket)，?并用協(xié)議開始前Client與KDC之間的密鑰將TGT加密回復(fù)給Client。

此時(shí)只有真正的Client才能利用它與KDC之間的密鑰將加密后的TGT解密，從而獲得TGT。

（此過程避免了Client直接向KDC發(fā)送密碼，以求通過驗(yàn)證的不安全方式）

2. Client利用之前獲得的TGT向KDC請(qǐng)求其他Service的Ticket，從而通過其他Service的身份鑒別。

?Kerberos協(xié)議的重點(diǎn)在于第二部分，簡(jiǎn)介如下：

?

1．????Client將之前獲得TGT和要請(qǐng)求的服務(wù)信息(服務(wù)名等)發(fā)送給KDC，KDC中的Ticket Granting Service將為Client和Service之間生成一個(gè)Session Key用于Service對(duì)Client的身份鑒別。然后KDC將這個(gè)Session Key和用戶名，用戶地址（IP），服務(wù)名，有效期,?時(shí)間戳一起包裝成一個(gè)Ticket(這些信息最終用于Service對(duì)Client的身份鑒別)發(fā)送給Service，?不過Kerberos協(xié)議并沒有直接將Ticket發(fā)送給Service，而是通過Client轉(zhuǎn)發(fā)給Service.所以有了第二步。

2．????此時(shí)KDC將剛才的Ticket轉(zhuǎn)發(fā)給Client。由于這個(gè)Ticket是要給Service的，不能讓Client看到，所以KDC用協(xié)議開始前KDC與Service之間的密鑰將Ticket加密后再發(fā)送給Client。同時(shí)為了讓Client和Service之間共享那個(gè)秘密(KDC在第一步為它們創(chuàng)建的Session Key)，?KDC用Client與它之間的密鑰將Session Key加密隨加密的Ticket一起返回給Client。

3．????為了完成Ticket的傳遞，Client將剛才收到的Ticket轉(zhuǎn)發(fā)到Service.?由于Client不知道KDC與Service之間的密鑰，所以它無法算改Ticket中的信息。同時(shí)Client將收到的Session Key解密出來，然后將自己的用戶名，用戶地址（IP）打包成Authenticator用Session Key加密也發(fā)送給Service。

4．????Service?收到Ticket后利用它與KDC之間的密鑰將Ticket中的信息解密出來，從而獲得Session Key和用戶名，用戶地址（IP），服務(wù)名，有效期。然后再用Session Key將Authenticator解密從而獲得用戶名，用戶地址（IP）將其與之前Ticket中解密出來的用戶名，用戶地址（IP）做比較從而驗(yàn)證Client的身份。

5．????如果Service有返回結(jié)果，將其返回給Client。

總結(jié)

概括起來說Kerberos協(xié)議主要做了兩件事

1．????Ticket的安全傳遞。

2．????Session Key的安全發(fā)布。

再加上時(shí)間戳的使用就很大程度上的保證了用戶鑒別的安全性。并且利用Session Key，在通過鑒別之后Client和Service之間傳遞的消息也可以獲得Confidentiality(機(jī)密性), Integrity(完整性)的保證。不過由于沒有使用非對(duì)稱密鑰自然也就無法具有抗否認(rèn)性，這也限制了它的應(yīng)用。不過相對(duì)而言它比X.509 PKI的身份鑒別方式實(shí)施起來要簡(jiǎn)單多了。

從kerberos協(xié)議的基礎(chǔ)原理，在Hadoop上的應(yīng)用，主要也就是兩個(gè)過程，KDC為客戶端上生成TGT，客戶端和服務(wù)端通過TGT認(rèn)證后通信。

2、Hadoop集群內(nèi)應(yīng)用kerberos認(rèn)證

Hadoop集群內(nèi)部使用Kerberos進(jìn)行認(rèn)證

具體的執(zhí)行過程可以舉例如下：

使用kerberos進(jìn)行驗(yàn)證的原因

• 可靠?Hadoop 本身并沒有認(rèn)證功能和創(chuàng)建用戶組功能，使用依靠外圍的認(rèn)證系統(tǒng)
• 高效?Kerberos使用對(duì)稱鑰匙操作，比SSL的公共密鑰快
• 操作簡(jiǎn)單?用戶可以方便進(jìn)行操作，不需要很復(fù)雜的指令。比如廢除一個(gè)用戶只需要從Kerbores的KDC數(shù)據(jù)庫中刪除即可。

如此，維護(hù)KDC數(shù)據(jù)庫是應(yīng)用kerberos協(xié)議的基礎(chǔ)。下面就看Hadoop上怎么增加Kerberos認(rèn)證。

3、Hadoop平臺(tái)上添加Kerberos認(rèn)證，首要兩步：

1）第一步自然是部署KDC，并配置KDC服務(wù)器上的相關(guān)文件，其中/etc/krb5.conf要復(fù)制到集群內(nèi)所有機(jī)子，并創(chuàng)建principal數(shù)據(jù)庫。

2）創(chuàng)建認(rèn)證規(guī)則principals和keytab，這個(gè)很重要，就是生成每個(gè)客戶端相應(yīng)的秘鑰，Keytab是融合主機(jī)和Linux上賬號(hào)而生成的，復(fù)制keytab到相應(yīng)節(jié)點(diǎn)。

可參考：http://blog.chinaunix.net/uid-1838361-id-3243243.html

4、Hadoop通過kerberos安全認(rèn)證的分析

Hadoop加入Kerberos認(rèn)證機(jī)制，使得集群中的節(jié)點(diǎn)是信賴的。Kerberos首先通過KDC生成指定節(jié)點(diǎn)包含主機(jī)和賬號(hào)信息的密鑰，然后將認(rèn)證的密鑰在集群部署時(shí)事先放到可靠的節(jié)點(diǎn)上。集群運(yùn)行時(shí)，集群內(nèi)的節(jié)點(diǎn)使用密鑰得到認(rèn)證，只有被認(rèn)證過節(jié)點(diǎn)才能正常使用。企圖冒充的節(jié)點(diǎn)由于沒有事先得到的密鑰信息，無法與集群內(nèi)部的節(jié)點(diǎn)通信。防止了惡意的使用或篡改Hadoop集群的問題，確保了Hadoop集群的可靠安全。

1）Hadoop的安全問題

——用戶到服務(wù)器的認(rèn)證問題
NameNode，,JobTracker上沒有用戶認(rèn)證
用戶可以偽裝成其他用戶入侵到一個(gè)HDFS 或者M(jìn)apReduce集群上。
DataNode上沒有認(rèn)證
Datanode對(duì)讀入輸出并沒有認(rèn)證。導(dǎo)致如果一些客戶端如果知道block的ID，就可以任意的訪問DataNode上block的數(shù)據(jù)
JobTracker上沒有認(rèn)證
可以任意的殺死或更改用戶的jobs，可以更改JobTracker的工作狀態(tài)
——服務(wù)器到服務(wù)器的認(rèn)證問題
沒有DataNode, TaskTracker的認(rèn)證
用戶可以偽裝成datanode ,tasktracker，去接受JobTracker, Namenode的任務(wù)指派。

2）Kerberos解決方案

kerberos實(shí)現(xiàn)的是機(jī)器級(jí)別的安全認(rèn)證，也就是前面提到的服務(wù)到服務(wù)的認(rèn)證問題。事先對(duì)集群中確定的機(jī)器由管理員手動(dòng)添加到kerberos數(shù)據(jù)庫中，在KDC上分別產(chǎn)生主機(jī)與各個(gè)節(jié)點(diǎn)的keytab(包含了host和對(duì)應(yīng)節(jié)點(diǎn)的名字，還有他們之間的密鑰)，并將這些keytab分發(fā)到對(duì)應(yīng)的節(jié)點(diǎn)上。通過這些keytab文件，節(jié)點(diǎn)可以從KDC上獲得與目標(biāo)節(jié)點(diǎn)通信的密鑰，進(jìn)而被目標(biāo)節(jié)點(diǎn)所認(rèn)證，提供相應(yīng)的服務(wù)，防止了被冒充的可能性。
——解決服務(wù)器到服務(wù)器的認(rèn)證
由于kerberos對(duì)集群里的所有機(jī)器都分發(fā)了keytab，相互之間使用密鑰進(jìn)行通信，確保不會(huì)冒充服務(wù)器的情況。集群中的機(jī)器就是它們所宣稱的，是可靠的。
防止了用戶偽裝成Datanode，Tasktracker，去接受JobTracker，Namenode的任務(wù)指派。
——解決client到服務(wù)器的認(rèn)證
Kerberos對(duì)可信任的客戶端提供認(rèn)證，確保他們可以執(zhí)行作業(yè)的相關(guān)操作。防止用戶惡意冒充client提交作業(yè)的情況。
用戶無法偽裝成其他用戶入侵到一個(gè)HDFS 或者M(jìn)apReduce集群上
用戶即使知道datanode的相關(guān)信息，也無法讀取HDFS上的數(shù)據(jù)
用戶無法發(fā)送對(duì)于作業(yè)的操作到JobTracker上
——對(duì)用戶級(jí)別上的認(rèn)證并沒有實(shí)現(xiàn)
無法控制用戶提交作業(yè)的操作。不能夠?qū)崿F(xiàn)限制用戶提交作業(yè)的權(quán)限。不能控制哪些用戶可以提交該類型的作業(yè)，哪些用戶不能提交該類型的作業(yè)。這個(gè)可以通過ACL來控制，對(duì)具體文件的讀寫訪問進(jìn)行有效管理。此前筆者對(duì)ACL有一個(gè)初步的了解，見博客http://blog.csdn.net/fjssharpsword/article/details/51280335

實(shí)際上，Hadoop平臺(tái)自身也在不斷完善，而對(duì)其集成的組件和整體機(jī)制了解，筆者也在不斷加深，此前的一些錯(cuò)誤認(rèn)識(shí)也在不斷調(diào)整。

總結(jié)

以上是生活随笔為你收集整理的Hadoop平台安全机制Kerberos认证的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。