? ?文章作者：luxianghao

? ?文章來源：http://www.cnblogs.com/luxianghao/p/5269739.html? 轉(zhuǎn)載請(qǐng)注明，謝謝合作。

? ?免責(zé)聲明：文章內(nèi)容僅代表個(gè)人觀點(diǎn)，如有不當(dāng)，歡迎指正。

? ?---?

一，引言

　　Kerberos簡(jiǎn)單來說就是一個(gè)用于安全認(rèn)證第三方協(xié)議，它采用了傳統(tǒng)的共享密鑰的方式，實(shí)現(xiàn)了在網(wǎng)絡(luò)環(huán)境不一定保證安全的環(huán)境下，client和server之間的通信，適用于client/server模型，由MIT開發(fā)和實(shí)現(xiàn)。

　　Kerberos的神秘之處在于，它并不要求通信雙方所在的網(wǎng)絡(luò)環(huán)境是安全的，即使通信過程中數(shù)據(jù)被截取或者篡改依然不會(huì)影響它的正常工作，它提供的認(rèn)證是雙向的，不僅能保證Server不被錯(cuò)誤的Client使用，同時(shí)也能保證Client不使用錯(cuò)誤的Server。同時(shí)Kerberos又嚴(yán)重依賴于時(shí)間，時(shí)間戳也是Kerberos用來保證通信安全的重要手段，這個(gè)一般通過通信雙方同時(shí)訪問同一個(gè)時(shí)間服務(wù)器來實(shí)現(xiàn)。Kerberos也能達(dá)到單點(diǎn)登錄的效果，即當(dāng)Client通過了Kerberos server的認(rèn)證后，便可以訪問多個(gè)Real Server。

?

二，Kerberos原理淺析

　　在實(shí)際的應(yīng)有場(chǎng)景中通常有三個(gè)角色，即需要訪問服務(wù)的Client，提供服務(wù)的Application Server，以及提供安全認(rèn)證的第三方Kerberos服務(wù)器KDC（Key Distribution Center）。它們彼此之間的認(rèn)證、通信的數(shù)據(jù)流如下圖所示。

　　　　　　

　　仔細(xì)研究過上圖之后，你可能會(huì)發(fā)現(xiàn)你能看明白的東西實(shí)在有限，而想要把Kerberos原理弄明白實(shí)在不是一件容易的事，不過可以慶幸的是Kerberos是用傳統(tǒng)的共享密鑰的方式實(shí)現(xiàn)的，這個(gè)概念對(duì)大家來說并不陌生，同時(shí)Kerberos認(rèn)證還加了時(shí)間戳，有效時(shí)間，信息對(duì)比等伎倆，所以花時(shí)間細(xì)細(xì)讀下來你依然能看明白，如果此時(shí)你就迫不及待的想研究的話你可以戳這里，這里，或者這里?，F(xiàn)在，我們來討論下Kerberos的認(rèn)證的一個(gè)部分，我認(rèn)為只要這個(gè)部分理解了，其他的都可以遞推出來。如下圖：

?　　　　　　

Client master key: KDC中存儲(chǔ)的Client的密鑰

Server master key: KDC中存儲(chǔ)的Server的密鑰

Sclient-Server：Client與Server之間的會(huì)話密鑰

Client Info：記錄了Client本身的Ip等基本信息

首先 Client詢問KDC，我想訪問某個(gè)Server，然后KDC會(huì)將會(huì)話密鑰Sclient-Server用Client master key加密后傳送給Client；與此同時(shí)，KDC也會(huì)將會(huì)話密鑰Sclient-Server連同Client的基本信息打包用Server master key加密也發(fā)給Client，并經(jīng)Client轉(zhuǎn)發(fā)給Server，至此Client與KDC的交互完成。

然后，Client用自己的master key解密KDC傳過來的第一個(gè)包，解密后獲得會(huì)話密鑰Sclient-Server，并用這個(gè)密鑰加密自己的的信息和時(shí)間戳打包后傳送給Server，此時(shí)Client開始和Server交互，如下圖： ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

　　　　　　

Server會(huì)收到兩個(gè)數(shù)據(jù)包，一個(gè)用會(huì)話密鑰加密，一個(gè)用自己的master key加密，Server先用自己的master key解密獲取會(huì)話密鑰和一份關(guān)于Client的信息，然后Server拿到解密后獲取到的會(huì)話密鑰再解開另外一個(gè)數(shù)據(jù)包，獲得另一份關(guān)于Client的信息和時(shí)間戳，至此Client和Server的交互完成。

下面我們解釋下這樣傳輸數(shù)據(jù)的原因，為什么傳遞這些數(shù)據(jù)

1，上面有個(gè)數(shù)據(jù)包是KDC經(jīng)Client轉(zhuǎn)發(fā)給Server的，為什么不直接發(fā)給Server？

因?yàn)镾erver可能給多個(gè)Client提供服務(wù)，這樣Server需要維護(hù)一個(gè)Client和會(huì)話密鑰的對(duì)應(yīng)表，這對(duì)Server是一個(gè)負(fù)擔(dān)。

此外，因?yàn)榫W(wǎng)絡(luò)傳輸?shù)牟淮_定性可能Client和Server并不能都及時(shí)獲取到會(huì)話密鑰，假如有一方獲取失敗，那么Client就不能訪問Server

2，為什么要發(fā)兩份關(guān)于Client的信息給Server？

通過這兩份數(shù)據(jù)的對(duì)比，Server就能判斷出是不是對(duì)的Client在訪問服務(wù)。

3，Client是如何判斷自己在訪問對(duì)的Server呢？

因?yàn)镃lient給Server的一個(gè)數(shù)據(jù)包是用Server的master key來加密的所以只有對(duì)的Server才能解密。

4，為什么要用會(huì)話密鑰

通信方的master key是長(zhǎng)期有效的，如果在網(wǎng)絡(luò)上傳輸，一旦被截取，理論上來說只要有足夠的時(shí)間是可以破解的，所以我們才用臨時(shí)的會(huì)話密鑰來通信，一段時(shí)間后會(huì)話密鑰會(huì)過期，同時(shí)時(shí)間戳也防止了，惡意用戶重復(fù)使用同一個(gè)數(shù)據(jù)包。

5，為什么要用時(shí)間戳？

如果Client向Server傳送的數(shù)據(jù)包被其他的Client截取，然后自己拿來向Server請(qǐng)求服務(wù)這，這樣就會(huì)出問題，那么引入時(shí)間戳后，Server收到請(qǐng)求后將從解密后的數(shù)據(jù)包中獲得的時(shí)間戳和當(dāng)前時(shí)間對(duì)比，一旦超過一定范圍將直接拒絕請(qǐng)求；所以，正如前面所說，Kerberos高度依賴時(shí)間同步服務(wù)。

事實(shí)上這個(gè)并不是Kerberos認(rèn)證的整個(gè)過程，KDC實(shí)際上由AS和TGS兩部分組成，你可以將TGS視作一個(gè)Server，然后還沿用上面所說的步驟來分析，這樣就可以基本上梳理出Client訪問Server的一個(gè)完整的過程了。

這些東西可能依然難于理解，你可以借助Kerberos經(jīng)典會(huì)話中的場(chǎng)景來理解，請(qǐng)戳這里或者這里。

?

三，Kerberos應(yīng)用

1，安裝Kerberos，搭建Kerberos環(huán)境，用yum安裝下列包即可

　　krb5-devel.x86_64?
　　krb5-libs.x86_64?
　　krb5-workstation.x86_64

　　krb5-server.x86_64 （僅server端需安裝）

如果你想了解詳細(xì)的安裝步驟以及配置，請(qǐng)戳這里

這里我們僅貼出配置krb5.conf&kdc.conf中的主要部分

?/etc/krb5.conf 中包含了realm的信息，里邊設(shè)置了server的地址，從而讓Client能夠找到Server，示例如下

[libdefaults]default_realm = ATHENA.MIT.EDU[realms]ATHENA.MIT.EDU = {kdc = kerberos.mit.eduadmin_server = kerberos.mit.edu}

/var/kerberos/krb5kdc/kdc.conf中主要保存了server端的配置，包括server端口，數(shù)據(jù)庫(kù)存放地址，票據(jù)有效期等，示例如下：

[kdcdefaults]kdc_ports = 88,750[realms]ATHENA.MIT.EDU = {kadmind_port = 749max_life = 12h 0m 0smax_renewable_life = 7d 0h 0m 0sdatabase_name = /var/krb5kdc/principalacl_file = /var/krb5kdc/kadm5.acl}

2， 名詞解釋

KDC：即Key Distribution Center, 密鑰分發(fā)中心，負(fù)責(zé)頒發(fā)憑證
Kinit：Kerberos認(rèn)證命令，可以使用密碼或者Keytab。
Realm：Kerberos的一個(gè)管理域，同一個(gè)域中的所有實(shí)體共享同一個(gè)數(shù)據(jù)庫(kù)
Principal：Kerberos主體，即我們通常所說的Kerberos賬號(hào)(name@realm) ，可以為某個(gè)服務(wù)或者某個(gè)用戶所使用
Keytab：以文件的形式呈現(xiàn)，存儲(chǔ)了一個(gè)或多個(gè)Principal的長(zhǎng)期的key，用途和密碼類似，用于kerberos認(rèn)證登錄；其存在的意義在于讓用戶不需要明文的存儲(chǔ)密碼，和程序交互時(shí)不需要人為交互來輸入密碼。

3，簡(jiǎn)單使用

在安裝好Kerberos和對(duì)Kerberos有一個(gè)簡(jiǎn)單的認(rèn)識(shí)之后，你就可以試用一下了，最基本的命令就是kinit，是Client用來從KDC獲取票據(jù)的，示例如下：

a，使用密碼： kinit name@realm 然后根據(jù)提示輸入密碼即可

b，使用keytab： kinit -kt /path/to/keytab name@realm

kinit成功之后你獲取的票據(jù)就會(huì)緩存到本地，可以用klist查看，實(shí)例如下：

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: h_test@XIAOMI.HADOOP

Valid starting Expires Service principal
03/13/16 17:08:42 03/14/16 17:08:42 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
renew until 03/11/26 17:08:42

從中也可以看到過期時(shí)間。

如果你要銷毀當(dāng)前獲取的票據(jù)，用kdestroy即可。

當(dāng)然在kinit之前，server端首先要有你的賬號(hào)，這就需要管理員使用addprinc命令在Kerberos數(shù)據(jù)庫(kù)中添加，更多詳情請(qǐng)戳這里。

4，Kerbeos在Hadoop上應(yīng)用

在Hadoop的早期版本（1.0.0）之前是沒有安全認(rèn)證機(jī)制的，集群默認(rèn)自己的節(jié)點(diǎn)都是安全的，這樣就導(dǎo)致了惡意用戶的輕易入侵，修改集群數(shù)據(jù)，修改任務(wù)狀態(tài)，提交任務(wù)等問題。

1.0.0后的版本加入Kerberos認(rèn)證后，部署集群時(shí)需要事先將密鑰放在要部署的節(jié)點(diǎn)上，這樣集群內(nèi)的節(jié)點(diǎn)都是通過認(rèn)證的節(jié)點(diǎn)，只有通過認(rèn)證的節(jié)點(diǎn)才能被正常使用，同樣，通過認(rèn)證的Client才能使用服務(wù)。

如果要結(jié)合上面所說的原理，那么將上面說的Server換成Hadoop集群中的Namenode，Datanode即可。

?

四，Kerberos賬號(hào)管理

Kerberos本身的數(shù)據(jù)庫(kù)中不能查看密碼的，也沒有保存賬號(hào)使用人等信息，所有的信息都需要以命令行的形式獲取，管理起來極不方便，因此我們就開發(fā)了一套基于Django web框架的Kerberos賬號(hào)管理系統(tǒng)（Kerberos Account Management System，簡(jiǎn)稱KAS），以此來提高管理員的工作效率，讓管理員更有效、更有條理的管理Kerberos賬號(hào)，KAS的基本組件如下：

權(quán)限管理模塊：設(shè)定了用戶，用戶組等角色；admin，read等權(quán)限類型；并將Kerberos賬號(hào)視作一種資源類型；這樣就有了某個(gè)角色，擁有某種資源的某種權(quán)限的一種通用架構(gòu)，所以，這個(gè)模塊適用于各種資源管理系統(tǒng)。

工具管理模塊：里邊包含了KAS需要的各種工具，例如KAS和Kerberos server交互的工具，郵件發(fā)送工具等。

賬號(hào)申請(qǐng)模塊：為了減少溝通成本，我們?cè)O(shè)計(jì)了用戶提交申請(qǐng)，管理員審批的賬戶申請(qǐng)流程，在審批階段用戶和管理員可以對(duì)申請(qǐng)賬號(hào)做出評(píng)論，并可以視情況對(duì)申請(qǐng)賬號(hào)做出重新編輯，撤銷申請(qǐng)等操作，一旦有人提交了申請(qǐng)，做出了評(píng)論，或者其他操作系統(tǒng)會(huì)發(fā)郵件通知管理員和用戶，以便減少賬號(hào)申請(qǐng)時(shí)間。

賬號(hào)管理模塊：對(duì)于通過審批的賬號(hào)，用戶可以查看密碼，導(dǎo)出賬號(hào)keytab，查看賬號(hào)owner等，對(duì)賬號(hào)有admin權(quán)限的賬戶還可以將賬號(hào)授權(quán)給他人使用，以此來減小管理員的工作量。

API模塊：由于有一些特殊人員因?yàn)楣ぷ鞯男枰?#xff0c;希望查看或者使用owner為其他人的賬號(hào)，所以我們?cè)O(shè)計(jì)了API模塊；當(dāng)有人需要使用API接口時(shí)，需要向管理員申請(qǐng)將自己設(shè)為超級(jí)用戶，同時(shí)超級(jí)用戶需要維護(hù)一個(gè)自己的機(jī)器列表，只有在此機(jī)器列表包含的Host上才能使用API接口，此外超級(jí)用戶還需要到系統(tǒng)中查看自己的auth_token，用于在使用API接口時(shí)做校驗(yàn)。

Replicate模塊：Web端的增刪改查等操作只是修改了MySQL數(shù)據(jù)庫(kù)，此時(shí)我們需要Replicate模塊將MySQL中的修改實(shí)時(shí)同步到Kerberos自己的數(shù)據(jù)庫(kù)中。

機(jī)房間同步模塊：當(dāng)多個(gè)機(jī)房都需要使用Kerberos認(rèn)證的時(shí)候，我們就需要機(jī)房間同步模塊將主Server上的修改同步到其他機(jī)房中來保證數(shù)據(jù)的一致性。

備份模塊：用于備份MySQL中和Kerberos Server中的數(shù)據(jù)以防數(shù)據(jù)丟失或者其他意外發(fā)生。

KAS的整體架構(gòu)圖如下：

?

服務(wù)的安全以及高可用：

對(duì)于Web Server我們采用了Keepalived vip漂移的方式來保證服務(wù)的高可用性，同一時(shí)刻只有一臺(tái)Server工作，寫MySQL數(shù)據(jù)庫(kù)。

主Server上的Replicate模塊會(huì)將MySQL中的修改實(shí)時(shí)同步到Kerberos Server中，又通過Rsync加密、增量傳輸?shù)姆绞桨阎鱏erver中的Kerberos數(shù)據(jù)庫(kù)的更改同步到其他的Kerberos Server的數(shù)據(jù)庫(kù)中（包括同機(jī)房的和不同機(jī)房的）。

通常一個(gè)機(jī)房中的Kerberos Server有兩個(gè)，我們采用LVS或者Keepalived的方式保證服務(wù)的高可用。

Web Server，Replicate模塊等的進(jìn)程我們用God的守護(hù)，以確保服務(wù)在異常停止后能自動(dòng)拉起。

此外，由于Kerbeos是比較基礎(chǔ)的服務(wù)，又比較敏感，所以我們還做了端口監(jiān)控，機(jī)器級(jí)別的安全加固等。

下面簡(jiǎn)單列一下KAS開發(fā)前后狀態(tài)的對(duì)比，如下：

到目前為止系統(tǒng)已經(jīng)上線近一年，期間運(yùn)行狀態(tài)良好，沒有出現(xiàn)過異常宕掉的情況，很好的提升了工作效率，節(jié)約了管理員的時(shí)間。

?

五，后記

至此，我們講述了一套完整的Kerberos服務(wù)使用及管理的方案，由于本人水平有限，其中難免出現(xiàn)一些錯(cuò)誤，還請(qǐng)諒解，歡迎批評(píng)指正。

轉(zhuǎn)載于:https://www.cnblogs.com/luxianghao/p/5269739.html

總結(jié)

以上是生活随笔為你收集整理的浅析Kerberos原理，及其应用和管理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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