kafka的安全機制基礎(chǔ)概念

kafka的安全性包括三個組成部分：

1. 數(shù)據(jù)加密(SSL)
   SSL解決的是數(shù)據(jù)安全的問題，使得kafka客戶端和kafka服務(wù)端之間傳輸?shù)臄?shù)據(jù)是加密的，傳輸過程中的數(shù)據(jù)不能被截取。
   當(dāng)然SSL證書也能解決身份問題，但這不是必須的。

2. 用戶認(rèn)證(SSL或者SASL)
   SASL: Simple Authorization Service Layer
   用戶認(rèn)證解決的是身份問題，即表明誰是誰。這有兩種方式：

   • SSL證書本身來表明身份；這就是SSL證書的另一個功能，身份標(biāo)識。
   • SASL使用(類似用戶名+密碼)來表明自己的身份。

   有了用戶認(rèn)證功能，就可以驗證這是不是一個有效的用戶啊，這樣就可以為訪問的安全性，以及后面的授權(quán)提供基礎(chǔ)。

3. 用戶授權(quán)
   用戶授權(quán)解決的的是用戶有什么權(quán)限的問題。 但是用戶授權(quán)必須依賴前面的用戶認(rèn)證，因為只有完成了身份認(rèn)證，確定了誰是誰的問題，才能對用戶授權(quán)。

所以組合起來有如下幾種組合：

認(rèn)證授權(quán)組合類型

1. SSL + ACL
   使用SSL的證書信息完成用戶認(rèn)證(依靠證書內(nèi)的身份信息)，使用ACL對證書用戶授權(quán)；另外數(shù)據(jù)傳輸是SSL加密安全的。
2. SASL + ACL
   使用SASL提供給的信息完成用戶認(rèn)證(用戶名+密碼)，使用ACL對SASL用戶授權(quán)；但是數(shù)據(jù)傳輸是明文的，不安全。
3. SSL + SASL + ACL
   使用SASL提供給的信息完成用戶認(rèn)證(用戶名+密碼)，使用ACL對SASL用戶授權(quán)；另外數(shù)據(jù)傳輸是SSL加密安全的。

這里有一個問題：

• 問：既然SSL+ACL已經(jīng)完全解決了認(rèn)證和授權(quán)以及傳輸安全的問題，為什么還需要SSL+SASL+ACL呢？
• 猜：我猜因為是用戶名賬號的格式問題。SASL提供的是原生的用戶賬號信息，這些賬戶可能存在系統(tǒng)賬號里面例如LDAP，這樣SSL和SASL賬號之間能夠打通；而SSL證書提供的賬號信息是SUBJ域的CN字段，這個CN域可能不能直接反應(yīng)現(xiàn)場用戶；另外證書可能是共享的域證書，不是單用戶證書。而且SSL證書可以只用來傳輸加密，不用來做身份認(rèn)證，例如我們沒有CA根證書來驗證SSL證書的身份，這樣就無法識別用戶身份，但是不妨礙繼續(xù)使用這種證書來為數(shù)據(jù)傳輸做加密；因為證書認(rèn)證需要CA根證書，而用在數(shù)據(jù)加密傳輸則不需要CA根證書。

SASL支持的模式

1. SASL PLAINTEXT:
   • 傳統(tǒng)用戶名/密碼驗證。
   • 用戶名/密碼以明文在網(wǎng)上傳輸。(建議開啟SSL)
   • 用戶名密碼需要事先存儲在kafka，所以更改用戶信息需要重啟kafka。

1. SASL SCRAM

   • 在用戶名/密碼的基礎(chǔ)上，增加了一個challenge salt
   • 用戶名/密碼以明文在網(wǎng)上傳輸。(建議開啟SSL)
   • 用戶名/密碼hash值存在在zookeeper上，這樣更改用戶信息可以不用重啟kafka

2. SASL GSSAPI (Kerberos):

   • 沒有弄過
   • 基于Kerberos

3. SASL OAUTHBEARER

   • kafka 2.0之后新增的

本頁內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁中由涉嫌抄襲的內(nèi)容，請及時與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會在5工作日內(nèi)聯(lián)系您，一經(jīng)查實，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://www.juherenli.com/20454.html