大家好，我是君哥。

我們?cè)谑褂孟㈥?duì)列時(shí)，經(jīng)常關(guān)注的是消息隊(duì)列收發(fā)消息的功能。但好多時(shí)候需要對(duì)客戶(hù)端有一定的限制，比如只有持有令牌的客戶(hù)端才能訪(fǎng)問(wèn)集權(quán)，不允許 Producer 發(fā)送消息到某一個(gè) Topic，或者某一個(gè) Topic 只能給固定 Consumer 消費(fèi)。

為了能對(duì)客戶(hù)端有一定限制，需要對(duì)消息隊(duì)列進(jìn)行認(rèn)證和鑒權(quán)，今天我們就來(lái)聊一聊主流消息隊(duì)列是怎么做認(rèn)證和鑒權(quán)的。

1.認(rèn)證

認(rèn)證是指通過(guò)一定手段，對(duì)訪(fǎng)問(wèn)用戶(hù)身份進(jìn)行校驗(yàn)，只有校驗(yàn)通過(guò)的用戶(hù)，才允許訪(fǎng)問(wèn)。

默認(rèn)情況下，主流消息隊(duì)列是不開(kāi)啟認(rèn)證的，這也意味著只要網(wǎng)絡(luò)能通，客戶(hù)端就可以訪(fǎng)問(wèn) Broker 集群，可以說(shuō)集群處于“裸奔”的狀態(tài)，有很大的風(fēng)險(xiǎn)。

消息隊(duì)列的認(rèn)證，是指對(duì)客戶(hù)端進(jìn)行身份確認(rèn)，只有認(rèn)證通過(guò)的客戶(hù)端才可以訪(fǎng)問(wèn) Broker 集群資源。

常見(jiàn)的認(rèn)證的方式有很多，主流消息隊(duì)列一般會(huì)定義一個(gè)認(rèn)證框架來(lái)制定認(rèn)證規(guī)則，然后通過(guò)實(shí)現(xiàn)這個(gè)框架來(lái)定義具體認(rèn)證方式。

（1）SSL/TLS

SSL(Secure Sockets Layer)是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議，消息隊(duì)列基于 SSL 的認(rèn)證是指 Broker 和客戶(hù)端的認(rèn)證，可以是單向認(rèn)證，也可以是雙向認(rèn)證。

消息隊(duì)列為了提升吞吐量，降低延遲，一般都是基于 TCP/IP 協(xié)議構(gòu)建的，SSL 協(xié)議位于應(yīng)用層和傳輸層之間。

使用 SSL 進(jìn)行通信前，客戶(hù)端和 Broker 都需要引入各自的證書(shū)，并且引入對(duì)應(yīng)編程語(yǔ)言的 SSL 庫(kù)。通信時(shí)，客戶(hù)端攜帶對(duì)應(yīng)的證書(shū)和公鑰信息，與 Broker 建立連接，Broker 則對(duì)客戶(hù)端進(jìn)行認(rèn)證，認(rèn)證成功后，客戶(hù)端才能進(jìn)行下一步操作。

Kafka 在早期的 0.9 版本引入了 SSL。

SSL3.0 版本后改名成 TLS，TLS 是 SSL 的升級(jí)版本。Pulsar 和 RabbitMQ 這 2 個(gè)消息隊(duì)列支持 TLS。

（2）SASL

SASL 全稱(chēng)是 Simple Authentication and Security Laye，是一種標(biāo)準(zhǔn)化的 C/S 身份認(rèn)證協(xié)議，客戶(hù)端和服務(wù)器基于這個(gè)協(xié)議交換身份信息，驗(yàn)證成功后才可以建立連接。

SASL 其實(shí)是一中認(rèn)證框架，基于這個(gè)框架我們可以實(shí)現(xiàn)多種認(rèn)證機(jī)制，比如用戶(hù)名密碼、Kerberos、NTLM、OAuth等。

Kafka 0.9.0.0 版本開(kāi)始支持 SASL，并且基于 SASL 實(shí)現(xiàn)了多種認(rèn)證插件。如下圖：

• GSSAPI 是用來(lái)支持 Kerberos 協(xié)議的，如果公司已經(jīng)做過(guò) Kerberos 認(rèn)證，那使用 GSSAPI 會(huì)非常方便。
• PLAIN 是一種使用用戶(hù)名密碼的認(rèn)證機(jī)制，可以跟 SSL 搭配使用，更加適合小公司的 Kafka 集群使用。PLAIN 有一個(gè)很大的缺點(diǎn)就是增加或刪除用戶(hù)，需要重啟 Broker 集群才能生效，因?yàn)檎J(rèn)證用戶(hù)保存在靜態(tài)文件中，Broker 集群不能動(dòng)態(tài)加載。
• SCRAM 將認(rèn)證用戶(hù)保存在 ZooKeeper，解決了 PLAIN 增加或刪除用戶(hù)需要重啟集群的問(wèn)題。
• OAUTHBEARER 是 Kafka 在 2.0 版本引入的，主要是為了實(shí)現(xiàn) OAuth2 認(rèn)證機(jī)制。
• Delegation Token 是 SASL 機(jī)制的補(bǔ)充，它是基于 Token 的一種認(rèn)證機(jī)制，它的特點(diǎn)是非常輕量級(jí)，用戶(hù)獲取到一次 Token 之后，后面的請(qǐng)求過(guò)程中可以繼續(xù)使用這個(gè) Token(除了 Token 更新)，無(wú)須再次獲取。

（3）AK/SK

RocketMQ 基于 AK/SK 實(shí)現(xiàn)認(rèn)證方式，通過(guò)對(duì)稱(chēng)加密來(lái)驗(yàn)證客戶(hù)端身份，保證認(rèn)證密碼不會(huì)以明文在網(wǎng)絡(luò)上傳輸，提升認(rèn)證安全。

客戶(hù)端發(fā)送請(qǐng)求時(shí)，使用加密算法對(duì)請(qǐng)求參數(shù)進(jìn)行加密，然后生成數(shù)字簽名，在請(qǐng)求中發(fā)送用戶(hù)名和簽名信息。Broker 收到請(qǐng)求后，首先查詢(xún)用戶(hù)名是否在本地庫(kù)(不存在則認(rèn)證失敗)，如果存在，則用相同的算法對(duì)請(qǐng)求進(jìn)行加密和簽名，然后比較簽名結(jié)果跟客戶(hù)端請(qǐng)求中的簽名信息是否一致。

（4）自定義框架

RabbitMQ 和 Pulsar 都提供了自定義、可插拔的身份認(rèn)證框架，然后基于框架的接口來(lái)實(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)起來(lái)也更加復(fù)雜。而自定義的機(jī)制則實(shí)現(xiàn)更加簡(jiǎn)單，同時(shí)也能滿(mǎn)足消息隊(duì)列的認(rèn)證需求。

下面對(duì)主流消息隊(duì)列使用的認(rèn)證方式總結(jié)如下：

2.鑒權(quán)

客戶(hù)端通過(guò)認(rèn)證后，就跟 Broker 建立了連接，但是并不是每個(gè)客戶(hù)端都可以操作所有的集群資源，比如銀行里面的不同業(yè)務(wù)數(shù)據(jù)不能給所有客戶(hù)端訪(fǎng)問(wèn)。這就需要對(duì)客戶(hù)端做資源訪(fǎng)問(wèn)限制。

授權(quán)是指對(duì)客戶(hù)端賦予一定的權(quán)限，比如允許客戶(hù)端從某一個(gè) Topic 拉取消息。

消息隊(duì)列對(duì)于資源的操作分為兩種，一種是運(yùn)維相關(guān)操作，比如創(chuàng)建 Topic、創(chuàng)建用戶(hù)等，權(quán)限一般分配給運(yùn)維人員。另一種是數(shù)據(jù)相關(guān)操作，包括生產(chǎn)消費(fèi)消息，權(quán)限一般分配給業(yè)務(wù)系統(tǒng)客戶(hù)端。

要實(shí)現(xiàn)資源控制，一般分成兩種方式，下面詳細(xì)介紹一下。

（1）鏈路分開(kāi)

如果分開(kāi)兩條鏈路來(lái)操作集群資源，一條鏈路由運(yùn)維人員來(lái)通過(guò) HTTP 來(lái)操作集群資源，另一條鏈路由業(yè)務(wù)系統(tǒng)客戶(hù)端通過(guò) TCP 來(lái)收發(fā)消息，這樣實(shí)現(xiàn)權(quán)限控制就非常容易，成本很低。

主流消息隊(duì)列 Pulsar 和 RabbitMQ 就是這種方式實(shí)現(xiàn)的。

這種方式也有一個(gè)問(wèn)題，就是集群中需要開(kāi)啟兩個(gè) Server 來(lái)服務(wù)兩個(gè)鏈路。

（2）一條鏈路

跟兩條鏈路相對(duì)應(yīng)的是，運(yùn)維操作和業(yè)務(wù)客戶(hù)端操作都通過(guò)一條鏈路來(lái)實(shí)現(xiàn)。

一條鏈路的方式集群不用啟動(dòng)兩個(gè) Server，但是需要根據(jù)用戶(hù)來(lái)分配權(quán)限，需要在代碼層面實(shí)現(xiàn)集群的資源控制，實(shí)現(xiàn)難度較大。主流消息隊(duì)列中的 Kafka 和 RocketMQ 就是用的這種方式。

（3）訪(fǎng)問(wèn)控制

無(wú)論是兩條鏈路還是一條鏈路，都無(wú)法細(xì)粒度地控制集群資源。比如運(yùn)維操作要限制某個(gè)用戶(hù)只能添加 Topic 而不能刪除 Topic，業(yè)務(wù)系統(tǒng)客戶(hù)端只被允許從某一個(gè) Topic 發(fā)送和消費(fèi)消息。

想要細(xì)粒度的控制集群資源，就需要引入鑒權(quán)模型，常見(jiàn)的鑒權(quán)模型如下：

• ACL：Access Control List，也就是訪(fǎng)問(wèn)控制列表，特點(diǎn)是直接把用戶(hù)和權(quán)限關(guān)聯(lián)起來(lái)。
• RBAC：Role Based Access Control，基于角色的權(quán)限控制，特點(diǎn)是引入了角色的概念，先將資源權(quán)限分配給角色，再把角色分配給用戶(hù)。
• ABAC：Attribute Based Access Control，基于屬性的權(quán)限控制，是一種動(dòng)態(tài)授權(quán)策略，他把用戶(hù)要訪(fǎng)問(wèn)的資源跟資源的屬性、環(huán)境因素結(jié)合起來(lái)，比如對(duì)一個(gè)資源的訪(fǎng)問(wèn)限制到時(shí)間級(jí)別。
• PBAC：Policy Based Access Control，基于策略的權(quán)限控制，可以基于任務(wù)或事件等其他不同的場(chǎng)景靈活配置訪(fǎng)問(wèn)權(quán)限。

（4）ACL

主流的消息隊(duì)列都是基于 ACL 來(lái)實(shí)現(xiàn)鑒權(quán)的。要實(shí)現(xiàn) ACL(Access Control List) ，首先需要定義好集群中有哪些資源或哪些操作需要做鑒權(quán)。

主流消息隊(duì)列中，Kafka 的資源或操作定義非常細(xì)致，資源包括：Topic、消費(fèi)者組、Broker 集群等，操作則包括：讀、寫(xiě)、創(chuàng)建、刪除、修改、訂閱等。Kafka 對(duì)資源的操作定義成不同接口(比如創(chuàng)建 Topic)，通過(guò)接口來(lái)做鑒權(quán)控制。見(jià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 中加入下面配置，就可以開(kāi)啟 ACL 鑒權(quán)：

authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer

其中 SimpleAclAuthorizer 是 Kafka 自帶的鑒權(quán)實(shí)現(xiàn)類(lèi)，這里也可以配置自定義的鑒權(quán)實(shí)現(xiàn)類(lèi)。

RabbitMQ 的架構(gòu)相對(duì)簡(jiǎn)單，定義的資源主要包括：Exchange、Queue 等，操作則包括讀、寫(xiě)、配置。因?yàn)?RabbitMQ 的集群配置是通過(guò) HTTP API 操作，所以并沒(méi)有提供接口維度的權(quán)限控制。

Pulsar 的鑒權(quán)包括生產(chǎn)、消費(fèi)、Lookup、Function、Source(從數(shù)據(jù)源讀取數(shù)據(jù))、Sink(數(shù)據(jù)存入下游)、Packages(保存用戶(hù)代碼包)。鑒權(quán)信息保存在 Zookeeper 的 /admin/policies/[namespace] 目錄下。Pulsar 也支持可插拔的授權(quán)框架，默認(rèn)實(shí)現(xiàn)類(lèi)是 PulsarAuthorizationProvider。

RocketMQ 中的 ACL 提供了 Topic 資源級(jí)別的用戶(hù)訪(fǎng)問(wèn)控制。用戶(hù)在使用 RocketMQ 權(quán)限控制時(shí)，可以在 Client 客戶(hù)端通過(guò) RPCHook 注入 AccessKey 和 SecretKey 簽名，同時(shí)將對(duì)應(yīng)的權(quán)限控制屬性（包括 Topic 訪(fǎng)問(wèn)權(quán)限、IP 白名單和 AccessKey 和 SecretKey 簽名等）設(shè)置在 distribution/conf/plain_acl.yml 的配置文件中。

RocketMQ 對(duì) Topic 資源訪(fǎng)問(wèn)權(quán)限控制定義了四種，下面表格來(lái)自官網(wǎng) ，

https://rocketmq.apache.org/zh/docs/4.x/bestPractice/04access/

權(quán)限定義的關(guān)鍵屬性參考 distribution/conf/plain_acl.yml 配置文件。

RocketMQ 的用戶(hù)分為普通用戶(hù)和管理員用戶(hù)，跟普通用戶(hù)相比，管理員用戶(hù)具有更新或創(chuàng)建主題、更新 Broker 配置、刪除主題、更新或創(chuàng)建訂閱組信息、刪除訂閱組信息等權(quán)限。

（5）超級(jí)用戶(hù)

消息隊(duì)列的超級(jí)用戶(hù)能夠訪(fǎng)問(wèn)集群中所有的資源，對(duì)集群運(yùn)維非常方便。比如分配出去的用戶(hù)密碼被惡意修改了，集群無(wú)法訪(fǎng)問(wèn)，這時(shí)超級(jí)用戶(hù)可以把密碼再改回來(lái)。超級(jí)用戶(hù)可以讓運(yùn)維人員方便地執(zhí)行緊急性、臨時(shí)性地操作。

超級(jí)用戶(hù)一般固定在配置文件中，客戶(hù)端對(duì)集群進(jìn)行訪(fǎng)問(wèn)控制的時(shí)候，集群對(duì)用戶(hù)是否是超級(jí)用戶(hù)進(jìn)行判斷。

Kafka 和 Pulsar 都有超級(jí)用戶(hù)的機(jī)制，RabbitMQ 則沒(méi)有超級(jí)用戶(hù)。

3.總結(jié)

默認(rèn)情況下，主流消息隊(duì)列都是不開(kāi)啟認(rèn)證和鑒權(quán)的。但在復(fù)雜的業(yè)務(wù)架構(gòu)中，為了保證隊(duì)列中數(shù)據(jù)安全性，必須開(kāi)啟認(rèn)證和鑒權(quán)。消息隊(duì)列的認(rèn)證機(jī)制有很多，鑒權(quán)則主要是通過(guò) ACL 來(lái)實(shí)現(xiàn)。希望本文能對(duì)你理解消息隊(duì)列的認(rèn)證和鑒權(quán)有所幫助。