kafka的安全機制基礎概念

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

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

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

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

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

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

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

認證授權組合類型

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

這里有一個問題：

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

SASL支持的模式

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

1. SASL SCRAM

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

2. SASL GSSAPI (Kerberos):

   • 沒有弄過
   • 基于Kerberos

3. SASL OAUTHBEARER

   • kafka 2.0之后新增的

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