聊聊主流消息隊(duì)列的認(rèn)證和鑒權(quán)!
大家好,我是君哥。
我們在使用消息隊(duì)列時(shí),經(jīng)常關(guān)注的是消息隊(duì)列收發(fā)消息的功能。但好多時(shí)候需要對客戶端有一定的限制,比如只有持有令牌的客戶端才能訪問集權(quán),不允許 Producer 發(fā)送消息到某一個(gè) Topic,或者某一個(gè) Topic 只能給固定 Consumer 消費(fèi)。
為了能對客戶端有一定限制,需要對消息隊(duì)列進(jìn)行認(rèn)證和鑒權(quán),今天我們就來聊一聊主流消息隊(duì)列是怎么做認(rèn)證和鑒權(quán)的。
1.認(rèn)證
認(rèn)證是指通過一定手段,對訪問用戶身份進(jìn)行校驗(yàn),只有校驗(yàn)通過的用戶,才允許訪問。
默認(rèn)情況下,主流消息隊(duì)列是不開啟認(rèn)證的,這也意味著只要網(wǎng)絡(luò)能通,客戶端就可以訪問 Broker 集群,可以說集群處于“裸奔”的狀態(tài),有很大的風(fēng)險(xiǎn)。
消息隊(duì)列的認(rèn)證,是指對客戶端進(jìn)行身份確認(rèn),只有認(rèn)證通過的客戶端才可以訪問 Broker 集群資源。
常見的認(rèn)證的方式有很多,主流消息隊(duì)列一般會(huì)定義一個(gè)認(rèn)證框架來制定認(rèn)證規(guī)則,然后通過實(shí)現(xiàn)這個(gè)框架來定義具體認(rèn)證方式。
(1)SSL/TLS
SSL(Secure Sockets Layer)是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議,消息隊(duì)列基于 SSL 的認(rèn)證是指 Broker 和客戶端的認(rèn)證,可以是單向認(rèn)證,也可以是雙向認(rèn)證。
消息隊(duì)列為了提升吞吐量,降低延遲,一般都是基于 TCP/IP 協(xié)議構(gòu)建的,SSL 協(xié)議位于應(yīng)用層和傳輸層之間。
使用 SSL 進(jìn)行通信前,客戶端和 Broker 都需要引入各自的證書,并且引入對應(yīng)編程語言的 SSL 庫。通信時(shí),客戶端攜帶對應(yīng)的證書和公鑰信息,與 Broker 建立連接,Broker 則對客戶端進(jìn)行認(rèn)證,認(rèn)證成功后,客戶端才能進(jìn)行下一步操作。
Kafka 在早期的 0.9 版本引入了 SSL。
SSL3.0 版本后改名成 TLS,TLS 是 SSL 的升級版本。Pulsar 和 RabbitMQ 這 2 個(gè)消息隊(duì)列支持 TLS。
(2)SASL
SASL 全稱是 Simple Authentication and Security Laye,是一種標(biāo)準(zhǔn)化的 C/S 身份認(rèn)證協(xié)議,客戶端和服務(wù)器基于這個(gè)協(xié)議交換身份信息,驗(yàn)證成功后才可以建立連接。
SASL 其實(shí)是一中認(rèn)證框架,基于這個(gè)框架我們可以實(shí)現(xiàn)多種認(rèn)證機(jī)制,比如用戶名密碼、Kerberos、NTLM、OAuth等。
Kafka 0.9.0.0 版本開始支持 SASL,并且基于 SASL 實(shí)現(xiàn)了多種認(rèn)證插件。如下圖:
- GSSAPI 是用來支持 Kerberos 協(xié)議的,如果公司已經(jīng)做過 Kerberos 認(rèn)證,那使用 GSSAPI 會(huì)非常方便。
- PLAIN 是一種使用用戶名密碼的認(rèn)證機(jī)制,可以跟 SSL 搭配使用,更加適合小公司的 Kafka 集群使用。PLAIN 有一個(gè)很大的缺點(diǎn)就是增加或刪除用戶,需要重啟 Broker 集群才能生效,因?yàn)檎J(rèn)證用戶保存在靜態(tài)文件中,Broker 集群不能動(dòng)態(tài)加載。
- SCRAM 將認(rèn)證用戶保存在 ZooKeeper,解決了 PLAIN 增加或刪除用戶需要重啟集群的問題。
- OAUTHBEARER 是 Kafka 在 2.0 版本引入的,主要是為了實(shí)現(xiàn) OAuth2 認(rèn)證機(jī)制。
- Delegation Token 是 SASL 機(jī)制的補(bǔ)充,它是基于 Token 的一種認(rèn)證機(jī)制,它的特點(diǎn)是非常輕量級,用戶獲取到一次 Token 之后,后面的請求過程中可以繼續(xù)使用這個(gè) Token(除了 Token 更新),無須再次獲取。
(3)AK/SK
RocketMQ 基于 AK/SK 實(shí)現(xiàn)認(rèn)證方式,通過對稱加密來驗(yàn)證客戶端身份,保證認(rèn)證密碼不會(huì)以明文在網(wǎng)絡(luò)上傳輸,提升認(rèn)證安全。
客戶端發(fā)送請求時(shí),使用加密算法對請求參數(shù)進(jìn)行加密,然后生成數(shù)字簽名,在請求中發(fā)送用戶名和簽名信息。Broker 收到請求后,首先查詢用戶名是否在本地庫(不存在則認(rèn)證失敗),如果存在,則用相同的算法對請求進(jìn)行加密和簽名,然后比較簽名結(jié)果跟客戶端請求中的簽名信息是否一致。
(4)自定義框架
RabbitMQ 和 Pulsar 都提供了自定義、可插拔的身份認(rèn)證框架,然后基于框架的接口來實(shí)現(xiàn)各種認(rèn)證插件,在配置文件中指定要使用的認(rèn)證插件。
Pulsar 內(nèi)置的認(rèn)證插件包括 JWT、OAuth2.0、Athenz、Kerberos 等。
RabbitMQ 實(shí)現(xiàn)的認(rèn)證插件包括 AMQPLAIN 和 PLAIN。
總結(jié):認(rèn)證框架的選擇很多,Kafka 選擇的 SASL 機(jī)制更加完善,功能更加強(qiáng)大,實(shí)現(xiàn)起來也更加復(fù)雜。而自定義的機(jī)制則實(shí)現(xiàn)更加簡單,同時(shí)也能滿足消息隊(duì)列的認(rèn)證需求。
下面對主流消息隊(duì)列使用的認(rèn)證方式總結(jié)如下:
消息隊(duì)列 | 認(rèn)證方式 |
Kafka | SASL:GSSAPI、PLAIN、SCRAM、OAUTHBEARER、Delegation Token |
RocketMQ | AK/SK |
RabbitMQ | AMQPLAIN、PLAIN |
Pulsar | JWT、OAuth2.0、Athenz、Kerberos |
2.鑒權(quán)
客戶端通過認(rèn)證后,就跟 Broker 建立了連接,但是并不是每個(gè)客戶端都可以操作所有的集群資源,比如銀行里面的不同業(yè)務(wù)數(shù)據(jù)不能給所有客戶端訪問。這就需要對客戶端做資源訪問限制。
授權(quán)是指對客戶端賦予一定的權(quán)限,比如允許客戶端從某一個(gè) Topic 拉取消息。
消息隊(duì)列對于資源的操作分為兩種,一種是運(yùn)維相關(guān)操作,比如創(chuàng)建 Topic、創(chuàng)建用戶等,權(quán)限一般分配給運(yùn)維人員。另一種是數(shù)據(jù)相關(guān)操作,包括生產(chǎn)消費(fèi)消息,權(quán)限一般分配給業(yè)務(wù)系統(tǒng)客戶端。
要實(shí)現(xiàn)資源控制,一般分成兩種方式,下面詳細(xì)介紹一下。
(1)鏈路分開
如果分開兩條鏈路來操作集群資源,一條鏈路由運(yùn)維人員來通過 HTTP 來操作集群資源,另一條鏈路由業(yè)務(wù)系統(tǒng)客戶端通過 TCP 來收發(fā)消息,這樣實(shí)現(xiàn)權(quán)限控制就非常容易,成本很低。
主流消息隊(duì)列 Pulsar 和 RabbitMQ 就是這種方式實(shí)現(xiàn)的。
這種方式也有一個(gè)問題,就是集群中需要開啟兩個(gè) Server 來服務(wù)兩個(gè)鏈路。
(2)一條鏈路
跟兩條鏈路相對應(yīng)的是,運(yùn)維操作和業(yè)務(wù)客戶端操作都通過一條鏈路來實(shí)現(xiàn)。
一條鏈路的方式集群不用啟動(dòng)兩個(gè) Server,但是需要根據(jù)用戶來分配權(quán)限,需要在代碼層面實(shí)現(xiàn)集群的資源控制,實(shí)現(xiàn)難度較大。主流消息隊(duì)列中的 Kafka 和 RocketMQ 就是用的這種方式。
(3)訪問控制
無論是兩條鏈路還是一條鏈路,都無法細(xì)粒度地控制集群資源。比如運(yùn)維操作要限制某個(gè)用戶只能添加 Topic 而不能刪除 Topic,業(yè)務(wù)系統(tǒng)客戶端只被允許從某一個(gè) Topic 發(fā)送和消費(fèi)消息。
想要細(xì)粒度的控制集群資源,就需要引入鑒權(quán)模型,常見的鑒權(quán)模型如下:
- ACL:Access Control List,也就是訪問控制列表,特點(diǎn)是直接把用戶和權(quán)限關(guān)聯(lián)起來。
- RBAC:Role Based Access Control,基于角色的權(quán)限控制,特點(diǎn)是引入了角色的概念,先將資源權(quán)限分配給角色,再把角色分配給用戶。
- ABAC:Attribute Based Access Control,基于屬性的權(quán)限控制,是一種動(dòng)態(tài)授權(quán)策略,他把用戶要訪問的資源跟資源的屬性、環(huán)境因素結(jié)合起來,比如對一個(gè)資源的訪問限制到時(shí)間級別。
- PBAC:Policy Based Access Control,基于策略的權(quán)限控制,可以基于任務(wù)或事件等其他不同的場景靈活配置訪問權(quán)限。
(4)ACL
主流的消息隊(duì)列都是基于 ACL 來實(shí)現(xiàn)鑒權(quán)的。要實(shí)現(xiàn) ACL(Access Control List) ,首先需要定義好集群中有哪些資源或哪些操作需要做鑒權(quán)。
主流消息隊(duì)列中,Kafka 的資源或操作定義非常細(xì)致,資源包括:Topic、消費(fèi)者組、Broker 集群等,操作則包括:讀、寫、創(chuàng)建、刪除、修改、訂閱等。Kafka 對資源的操作定義成不同接口(比如創(chuàng)建 Topic),通過接口來做鑒權(quán)控制。見官網(wǎng) KIP-11 下面鏈接。
https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authorization+Interface
Kafka 實(shí)現(xiàn)了可插拔的授權(quán)機(jī)制,該機(jī)制把所有 ACL 項(xiàng)保存在 ZooKeeper,Zookeeper 創(chuàng)建 /kafka-acl 節(jié)點(diǎn)進(jìn)行保存。Kafka 提供了 kafka-acls 腳本,可以動(dòng)態(tài)修改 ACL 配置項(xiàng),并且可以立即生效。在 server.properties 中加入下面配置,就可以開啟 ACL 鑒權(quán):
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
其中 SimpleAclAuthorizer 是 Kafka 自帶的鑒權(quán)實(shí)現(xiàn)類,這里也可以配置自定義的鑒權(quán)實(shí)現(xiàn)類。
RabbitMQ 的架構(gòu)相對簡單,定義的資源主要包括:Exchange、Queue 等,操作則包括讀、寫、配置。因?yàn)?RabbitMQ 的集群配置是通過 HTTP API 操作,所以并沒有提供接口維度的權(quán)限控制。
Pulsar 的鑒權(quán)包括生產(chǎn)、消費(fèi)、Lookup、Function、Source(從數(shù)據(jù)源讀取數(shù)據(jù))、Sink(數(shù)據(jù)存入下游)、Packages(保存用戶代碼包)。鑒權(quán)信息保存在 Zookeeper 的 /admin/policies/[namespace] 目錄下。Pulsar 也支持可插拔的授權(quán)框架,默認(rèn)實(shí)現(xiàn)類是 PulsarAuthorizationProvider。
RocketMQ 中的 ACL 提供了 Topic 資源級別的用戶訪問控制。用戶在使用 RocketMQ 權(quán)限控制時(shí),可以在 Client 客戶端通過 RPCHook 注入 AccessKey 和 SecretKey 簽名,同時(shí)將對應(yīng)的權(quán)限控制屬性(包括 Topic 訪問權(quán)限、IP 白名單和 AccessKey 和 SecretKey 簽名等)設(shè)置在 distribution/conf/plain_acl.yml 的配置文件中。
RocketMQ 對 Topic 資源訪問權(quán)限控制定義了四種,下面表格來自官網(wǎng) ,
https://rocketmq.apache.org/zh/docs/4.x/bestPractice/04access/
權(quán)限 | 含義 |
DENY | 拒絕 |
ANY | PUB 或者 SUB 權(quán)限 |
PUB | 發(fā)送權(quán)限 |
SUB | 訂閱權(quán)限 |
權(quán)限定義的關(guān)鍵屬性參考 distribution/conf/plain_acl.yml 配置文件。
RocketMQ 的用戶分為普通用戶和管理員用戶,跟普通用戶相比,管理員用戶具有更新或創(chuàng)建主題、更新 Broker 配置、刪除主題、更新或創(chuàng)建訂閱組信息、刪除訂閱組信息等權(quán)限。
(5)超級用戶
消息隊(duì)列的超級用戶能夠訪問集群中所有的資源,對集群運(yùn)維非常方便。比如分配出去的用戶密碼被惡意修改了,集群無法訪問,這時(shí)超級用戶可以把密碼再改回來。超級用戶可以讓運(yùn)維人員方便地執(zhí)行緊急性、臨時(shí)性地操作。
超級用戶一般固定在配置文件中,客戶端對集群進(jìn)行訪問控制的時(shí)候,集群對用戶是否是超級用戶進(jìn)行判斷。
Kafka 和 Pulsar 都有超級用戶的機(jī)制,RabbitMQ 則沒有超級用戶。
3.總結(jié)
默認(rèn)情況下,主流消息隊(duì)列都是不開啟認(rèn)證和鑒權(quán)的。但在復(fù)雜的業(yè)務(wù)架構(gòu)中,為了保證隊(duì)列中數(shù)據(jù)安全性,必須開啟認(rèn)證和鑒權(quán)。消息隊(duì)列的認(rèn)證機(jī)制有很多,鑒權(quán)則主要是通過 ACL 來實(shí)現(xiàn)。希望本文能對你理解消息隊(duì)列的認(rèn)證和鑒權(quán)有所幫助。