Apache RocketMQ ACL 2.0 全新升級

引言

RocketMQ 作為一款流行的分散式訊息中介軟體，被廣泛應用於各種大型分散式系統和微服務中，承擔著非同步通訊、系統解耦、削峰填谷和訊息通知等重要的角色。隨著技術的演進和業務規模的擴大，安全相關的挑戰日益突出，訊息系統的訪問控制也變得尤為重要。然而，RocketMQ 現有的 ACL 1.0 版本已經無法滿足未來的發展。因此，我們推出了 RocketMQ ACL 2.0 升級版，進一步提升 RocketMQ 資料的安全性。本文將介紹 RocketMQ ACL 2.0 的新特性、工作原理，以及相關的配置和實踐。

升級的背景

ACL 1.0 痛點問題

RocketMQ ACL 1.0 的認證和授權流程如上圖所示，在使用過程中，存在著以下痛點問題：

繞過訪問控制的 IP 白名單：在標準安全實踐中，IP 白名單通常用於限制客戶端只能從特定 IP 或 IP 段訪問資源。然而，ACL 1.0 中，IP 白名單被異常用於繞過鑑權驗證的手段， 偏離了標準實踐中的安全意圖。這種設計上的偏差可能造成潛在的安全隱患，特別是在公網場景中，多個客戶端共享同一個 IP 的情況下，會導致未授權的 IP 地址繞過正常的訪問控制檢查對叢集中的資料進行訪問。

缺乏管控 API 精細化控制：RocketMQ 提供了 130 多個管控 API，支援了叢集配置，Topic、Group 的後設資料管理，以及訊息查詢、位點重置等操作。這些操作涉及到敏感資料的處理，以及影響系統的穩定性。因此，根據使用者不同角色或職責，精確定義可訪問的 API 和資料範圍變得至關重要。然而，ACL 1.0 僅對其中 9 個 API 進行了支援，包括 Topic、Group 後設資料，以及Broker配置，剩下的 API 有可能被攻擊者利用，對系統進行攻擊，竊取敏感的資料。此外，要實施對這麼多的管控 API 進行訪問控制，現有的設計會導致大量的編碼工作，並且在新增 API 時也增加了遺漏的風險。

缺少叢集元件間訪問控制：在 RocketMQ 架構中，涵蓋了 NameServer、Broker 主從節點、Proxy 等多個關鍵元件。目前，這些元件之間的互相訪問缺失了關鍵的的許可權驗證機制。因此，一但旦在叢集外自行搭建 Broker 從節點或 Proxy 元件，便可以繞過現有的安全機制，訪問並獲取叢集內的敏感資料，這無疑給系統的資料安全和叢集的穩定性造成巨大的威脅。

特性與原理

ACL 2.0 新特性

RocketMQ ACL 2.0 針對 ACL 1.0 中的問題進行了解決，同時還帶來了六個主要的新特性，具體如下：

精細的API資源許可權定義：ACL 2.0 對 RocketMQ 系統中所有的資源都進行了定義，包括叢集、名稱空間、主題、消費者組，以實現對所有型別的資源進行獨立的訪問控制。此外，它將所有的 API 都納入許可權控制範疇，覆蓋了包括訊息收發、叢集管理、後設資料等各項操作，確保所有資源的任何操作都施加了嚴格的許可權控制。

授權資源的多種匹配模式：在資源眾多的叢集環境中，為每個資源進行逐一授權會帶來繁複的配置過程和管理負擔。因此，ACL 2.0 引入了三種靈活的匹配模式：完全匹配、字首匹配，以及萬用字元匹配。這些模式可以讓使用者根據資源的命名規範和結構特點，快速地進行統一的設定，簡化許可權的管理操作，提升配置的效率。

支援叢集元件間訪問控制：由於將所有資源型別和API操作都納入了訪問控制體系，叢集內部元件之間的連線和訪問也受到了許可權控制，包括 Broker 主從之間的 Leader 選舉、資料複製的過程，以及 Proxy 到 Broker 的資料訪問等環節，這可以有效地避免潛在的資料洩露問題和對系統穩定性的風險，加強了整個叢集的安全性和可靠性。

使用者認證和許可權校驗分離：透過對認證和授權這兩個關鍵模組進行解耦，系統可以提供類似“只認證不鑑權”等方式的靈活選擇，以適應各種不同場景的需求。此外，兩個元件可以分別演進、獨立發展，從而誕生出多樣的認證方式和先進的鑑權方法。

安全性和效能之間的平衡：當啟用 ACL 後，客戶端的每次請求都必須會經過完整的認證和授權流程。這確保了系統的安全性，但同時也引入了效能上的開銷。在 ACL 2.0 中，提供了無狀態認證授權策略和有狀態認證授權策略，來分別滿足對安全有極致要求，以及安全可控但效能優先這兩種不同的安全和效能需求。

靈活可擴充套件的外掛化機制：當前市場上，認證方式存在多種實現，授權方式也有不同場景的定製需求。因此，ACL 2.0 設計了一套外掛化的框架，在不同層面上進行介面的定義和抽象，以支援未來對認證和授權進行擴充套件，滿足使用者根據自身業務需求定製和實現相應的解決方案。

訪問控制模型

基於角色的訪問控制（RBAC）和基於屬性的訪問控制（ABAC）是訪問控制體系中兩種主要的方法。RocketMQ ACL 2.0 將這兩種方法進行了融合，打造出了一套更加靈活和強大的訪問控制系統。

RBAC 是基於角色的訪問控制模型，透過角色進行許可權的分配。RocketMQ ACL 2.0 將使用者角色劃分為超級使用者（Super）和普通使用者（Normal），超級使用者具有最高階別的許可權，能夠無需授權即可訪問資源，這簡化了叢集初始化及日常運維過程中的許可權依賴問題。而普通使用者在訪問資源之前，需要被賦予相應的許可權，適用於業務場景中，對資源進行按需訪問。

ABAC 是基於屬性的訪問控制模型，透過使用者、資源、環境、操作等多維屬性來表達訪問控制策略。RocketMQ ACL 2.0 為普通使用者提供了這種靈活的訪問控制機制。幫助管理員根據業務需求、使用者職責等因素，對資源進行更加精細的訪問控制。

在安全體系中，認證和授權分別扮演著不同的角色，RocetMQ ACL 2.0 將認證和授權進行了模組分離。這可以確保兩個元件各司其職，降低系統的複雜度。認證服務致力於驗證使用者身份的合法性，而授權服務則專注於管理使用者許可權和訪問控制。這樣的劃分不僅可以讓程式碼更易於管理、維護和擴充套件，也為使用者提供了使用上的靈活性。根據需求，使用者可以選擇單獨啟用認證或授權服務，也可以選擇同時啟用兩者。這使得 RocketMQ ACL 既可以滿足簡單場景的快速部署，也能夠適應複雜環境下對安全性的嚴格要求。

認證（Authentication）

認證作為一種安全機制，旨在驗證發起訪問請求者的身份真實性。它用於確保只有那些經過身份驗證的合法使用者或實體才能訪問受保護的資源或執行特定的操作。簡而言之，認證就是在資源或服務被訪問之前回答“你是誰？”這個問題。

RocketMQ ACL 2.0 版本維持了與 ACL 1.0 相同的認證機制，即基於 AK/SK 的認證方式。這種方式主要透過對稱加密技術來核驗客戶端的身份，保證敏感的認證資訊（如密碼）不會在網路上明文傳輸，從而提升了整體的認證安全性。

主體模型

為了提升 RocketMQ 系統的訪問控制和許可權管理，ACL 2.0 針對主體模型做了以下改進和擴充套件：

1. 統一主體模型的抽象：為了實現不同實體的訪問控制和許可權管理，設計了統一的主體介面，允許系統中多個例項作為資源訪問的主體。使用者作為訪問資源的主體之一，按照該模型實現了主體的介面。這為未來新實體型別的許可權適配提供了擴充套件能力。
2. 角色分級與許可權賦予：

• 超級使用者：為了簡化管理流程，超級使用者被自動授予了全部許可權，無需單獨配置，從而簡化了系統的初始化和日常的運維管理工作。
• 普通使用者：普通使用者的許可權則需要明確授權。ACL 2.0 提供了相關的許可權管理工具，可以根據組織的政策和安全需求，為普通使用者賦予合適的許可權。

3.支援使用者狀態管理：為了應對可能出現的安全風險，比如使用者密碼洩露，ACL 2.0 提供了使用者的啟用與禁用功能。當發生安全事件，可以透過禁用使用者狀態，快速進行止血，從而達到阻止非法訪問的目的。

認證流程

客戶端流程：

1. 客戶端在構建 RPC 請求時，檢查是否設定了使用者名稱和密碼，若未配置，則直接傳送請求；
2. 若已配置，則使用預設的加密演算法對請求引數進行加密處理，並生成對應的數字簽名（Signature）。
3. 在請求中附加使用者名稱和 Signature，並將其傳送至服務端以進行身份驗證。

服務端流程：

1. 服務端接收到請求後，首先檢查是否開啟認證，若未開啟，則不校驗直接透過；若已開啟了，則進入下一步。
2. 服務端對請求進行認證相關的引數進行解析和組裝，獲取包括使用者名稱和 Signature 等資訊。
3. 透過使用者名稱在本地庫中查詢使用者相關資訊，使用者不存在，則返回處理無；使用者存在，則進入下一步。
4. 獲取使用者密碼，採用相同的加密演算法對請求進行加密生成 Signature，並和客戶端傳遞的 Signature 進行比對，若兩者一致，則認證成功，不一致，則認證失敗。

授權（Authorization）

核心概念

授權作為一種安全機制，旨在確定訪問請求者是否擁有對特定資源進行操作的許可權。簡而言之，授權就是在資源被訪問之前回答“誰在何種環境下對哪些資源執行何種操作”這個問題。

基於“屬性的訪問控制（ABAC）”模型，RocketMQ ACL 2.0 涵蓋了以下一系列的核心概念。在系統實現中，都會以以下概念作為指導，完成整個許可權管理和授權機制的設計和實現。

許可權模型

基於屬性的訪問控制（ABAC）模型的核心概念，ACL 2.0 對許可權模型做了精心的設計，要點如下：

向後相容的許可權策略：預設情況下，ACL 2.0 只匹配和檢驗使用者自定義的許可權，若未找到匹配項，則視為無許可權訪問資源。但考慮到 ACL 1.0 中，存在預設許可權的設定，允許對未匹配資源進行“無許可權訪問”和“有許可權訪問”的預設判定。因此，我們針對預設許可權策略進行了相容，確保 ACL 1.0 到 ACL 2.0 的無縫遷移。

靈活的資源匹配模式：在資源型別方面，ACL 2.0 支援了叢集（Cluster）、名稱空間（Namespace）、主題（Topic）、消費者組（Group）等型別，用於對不同型別的資源進行訪問控制。在資源名稱方面，引入了完全匹配（LITERAL）、字首匹配（PREFIXED），以及萬用字元匹配（ANY）三種模式，方便使用者根據資源的命名規範和結構，快速設定統一的訪問規則，簡化許可權的管理。

精細的資源操作型別：在訊息的傳送和消費的介面方面，分別定義為 PUB 和 SUB 這兩種操作。在叢集和資源的管理的介面方面，分別定義為 CREATE、UPDATE、DELETE、LIST、GET 五種操作。透過這種操作型別的細化，可以幫助使用者在資源的操作層面，無需關心具體的介面定義，簡化對操作的理解和配置。

堅實的訪問環境校驗：在請求訪問的環境方面，ACL 2.0 加入了客戶端請求 IP 來源的校驗，這個校驗控制在每個資源的級別，可以精確到對每個資源進行控制。IP 來源可以是特定的 IP 地址或者是一個 IP 段，來滿足不同粒度的 IP 訪問控制，為系統的安全性增添一道堅實的防線。

授權流程

客戶端流程：

1. 客戶端在構建 RPC 請求時，構建本次呼叫的介面入參，介面對應許可權背後的操作定義。
2. 客戶端在介面入參中設定本次訪問的資源資訊，然後將使用者和資源等引數傳遞到服務端。

服務端流程：

1. 服務端在收到請求後，首先檢查是否開啟授權，若未開啟，則不校驗直接透過；若已開啟了，則進入下一步。
2. 服務端對請求中和授權相關的引數進行解析和組裝，這些資料包括使用者資訊、訪問的資源、執行的操作，以及請求的環境等。
3. 透過使用者名稱在本地資料儲存中查詢使用者相關資訊，若使用者不存在，則返回錯誤；若使用者存在，則進入下一步。
4. 判斷當前使用者是否是超級使用者，若超級使用者，則直接透過請求，無需做授權檢查，若普通使用者，則進入下一步進行詳細的授權檢查。
5. 根據使用者名稱獲取相關的授權策略列表，並對本次請求的資源、操作，以及環境進行匹配，同時按照優先順序進行排序。
6. 根據優先順序最高的授權策略做出決策，若授權策略允許該操作，則返回授權成功，若拒絕該操作，則返回無許可權錯誤。

授權引數的解析

在 ACL 2.0 中，更具操作型別和請求頻率，對授權相關引數（包括資源、操作等）的解析進行了最佳化。

1. 硬編碼方式解析

對於訊息傳送和消費這類介面，引數相對較為複雜，且請求頻次也相對較高。考慮到解析的便捷性和效能上的要求，採用硬編碼的方式進行解析。

2. 註解方式解析

對於大量的管控介面，採用硬編碼的方式工作量巨大，且這些介面呼叫頻次較低，對效能要求不高，所以採用註解的方式進行解析，提高編碼效率。

許可權策略優先順序

在許可權策略匹配方面，由於支援了模糊的資源匹配模式，可能出現同一個資源對應多個許可權策略。因此，需要一套優先順序的機制來確定最終使用哪一套許可權策略。

假設配置了以下授權策略，按照以上優先順序資源的匹配情況如下：

認證授權策略

出於安全和效能的權衡和考慮，RocketMQ ACL 2.0 為認證和授權提供了兩種策略：無狀態認證授權策略（Stateless）和有狀態認證授權策略（Stateful）。

無狀態認證授權策略（Stateless）: 在這種策略下，每個請求都會經過獨立的認證和授權過程，不依賴於任何先前的會話和狀態資訊。這種嚴格的策略可以保證更高階別的安全保證。對許可權進行變更，可以更加實時的反應在隨後的請求中，無需任何等待。然而，這種策略在高吞吐的場景中可能會導致顯著的效能負擔，如增加系統 CPU 的使用率以及請求的耗時。

有狀態認證授權策略（Stateful）: 在這種策略下，同一個客戶端連線，相同資源以及相同的操作下，第一次請求會經過完整的認證和授權，後續請求則不再進行重複認證和授權。這種方法可以有效地降低效能小號，減少請求的耗時，特別適合吞吐量較高的場景。但是，這種策略可能引入了安全上的妥協，對許可權的變更也無法做到實時的生效。

在這兩者策略的選擇上，需要權衡系統的安全性要求和效能需求。如果系統對安全性的要求很高，並且可以容忍一定的效能損耗，那麼無狀態認證授權策略可能是更好的選擇。相反，如果系統需要處理大量的併發請求，且可以在一定程度上放寬安全要求，那麼有狀態認證授權策略可能更合適。在實際部署時，還應該結合具體的業務場景和安全要求來做出決策。

外掛化機制

為了適應未來持續發展的認證鑑權方式，以及滿足使用者針對特定場景的定製需求，RocketMQ ACL 2.0 在多個環節上提供了靈活性和可擴充套件性。

認證和授權策略的擴充套件：預設情況下，RocketMQ ACL 2.0 提供了無狀態認證授權策略（Stateless）和有狀態認證授權策略（Stateful），以滿足絕大多數使用者對安全和效能的要求。但是，後續仍然可以探索出更優的策略，來兼顧安全和效能之間的平衡。

認證和授權方式的擴充套件：當前，在認證方面，市場上已經沉澱了多種成熟的實現，RocketMQ 目前只實現了其中一種，透過外掛化的能力進行預留，未來可以輕鬆的引入更多的認證機制。在授權方面，RocketMQ 基於 ABAC 模型實現了一套主流的授權方式，以適應廣泛的使用者需求。但也提供了外掛化的能力，方便未來能適配出更多貼合未來發展的解決方案。

認證和授權流程的編排：基於責任鏈設計模式，RocketMQ ACL 2.0 對其預設的認證和授權流程進行了靈活的編排。使用者可以擴充套件或重寫這些責任鏈節點，從而能夠定製針對其具體業務場景的認證和授權邏輯。

使用者和許可權儲存的擴充套件：RocketMQ 預設採用 RocksDB 在 Broker 節點上本地儲存使用者和許可權資料。然而，透過實現預定義的介面，使用者可以輕鬆地將這些資料遷移至任何第三方服務或儲存系統中，從而最佳化其架構設計和操作效率。

審計日誌

審計日誌，用於記錄和監控所有關於認證和授權的訪問控制操作。透過升級日誌，我們可以追蹤到每一個訪問的請求，確保系統的可靠性和安全性，同時，它也有助於問題的排查，進行安全的升級和滿足合規的要求。

RocketMQ ACL 2.0 對認證和授權相關的審計日誌都進行了支援，格式如下：

認證日誌

# 認證成功日誌
[AUTHENTICATION] User:rocketmq is authenticated success with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+gg=.

# 認證失敗日誌
[AUTHENTICATION] User:rocketmq is authenticated failed with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+xx=.

授權日誌

# 授權成功日誌
[AUTHORIZATION] Subject = User:rocketmq is Allow Action = Pub from sourceIp = 192.168.0.2 on resource = Topic:TP-TEST for request = 10.

# 授權失敗日誌
[AUTHORIZATION] Subject = User:rocketmq is Deny Action = Sub from sourceIp = 192.168.0.2 on resource = Topic:GID-TEST for request = 10.

配置與使用

部署架構

在部署架構方面，RocketMQ 提供了兩種部署形態，分別是存算一體架構和存算分離架構。

存算一體架構

在 RocketMQ 存算一體架構中，Broker 元件同時承擔了計算和儲存的職責，並對外提供服務，接收所有客戶端的訪問請求。因此，由 Broker 元件承擔認證和授權的重要角色。此外，Broker 元件還負責認證和授權相關的後設資料的維護和儲存。

存算分離架構

在 RocketMQ 存算分離架構中，儲存由 Broker 元件負責，計算由 Proxy 元件負責，所有的對外請求都是由 Proxy 對外進行服務。因此，請求的認證和授權都由 Proxy 元件承擔。Broker 承擔後設資料儲存，為 Proxy 元件提供所需的認證和授權後設資料的查詢和管理服務。

叢集配置

認證配置

引數列表

想要在服務端開啟認證功能，相關的引數和使用案例主要包含如下：

Broker 配置

authenticationEnabled = true
authenticationProvider = org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider
initAuthenticationUser = {"username":"rocketmq","password":"12345678"}
innerClientAuthenticationCredentials = {"accessKey":"rocketmq","secretKey":"12345678"}
authenticationMetadataProvider = org.apache.rocketmq.auth.authentication.provider.LocalAuthenticationMetadataProvider

Proxy 配置

{
  "authenticationEnabled": true,
  "authenticationProvider": "org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider",
  "authenticationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthenticationMetadataProvider",
  "innerClientAuthenticationCredentials": "{\"accessKey\":\"rocketmq\", \"secretKey\":\"12345678\"}"
}

授權配置

引數列表

想要在服務端開啟授權功能，相關的引數和使用案例主要包含如下：

Broker 配置

authorizationEnabled = true
authorizationProvider = org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider
authorizationMetadataProvider = org.apache.rocketmq.auth.authorization.provider.LocalAuthorizationMetadataProvider

Proxy 配置

{
  "authorizationEnabled": true,
  "authorizationProvider": "org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider",
  "authorizationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthorizationMetadataProvider"
}

如何使用

命令列使用

使用者管理

關於 ACL 使用者的管理，相關的介面定義和使用案例如下。

介面定義

使用案例

# 建立使用者
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq
# 建立使用者，指定使用者型別
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq -t Super
# 更新使用者
sh mqadmin updateUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p 12345678
# 刪除使用者
sh mqadmin deleteUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查詢使用者詳情
sh mqadmin getUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查詢使用者列表
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster
# 查詢使用者列表，帶過濾條件
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster -f mq

ACL 管理

關於 ACL 授權的管理，相關的介面定義和使用案例如下。

介面定義

使用案例

# 建立授權
sh mqadmin createAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Allow
# 更新授權
sh mqadmin updateAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Deny
# 刪除授權
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq
# 刪除授權，指定資源
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查詢授權列表
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster
# 查詢授權列表，帶過濾條件
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查詢授權詳情
sh mqadmin getAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq

客戶端使用

關於 ACL 的使用，ACL 2.0 和 ACL 1.0 的使用方式一樣，沒有任何區別，具體參考官方案例。

訊息傳送

ClientServiceProvider provider = ClientServiceProvider.loadService();
StaticSessionCredentialsProvider sessionCredentialsProvider = 
  new StaticSessionCredentialsProvider(ACCESS_KEY, SECRET_KEY);
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
Producer producer = provider.newProducerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setTopics(TOPICS)
    .build();

訊息消費

ClientServiceProvider provider = ClientServiceProvider.loadService();
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
FilterExpression filterExpression = new FilterExpression(TAG, FilterExpressionType.TAG);
PushConsumer pushConsumer = provider.newPushConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setConsumerGroup(CONSUMER_GROUP)
    .setSubscriptionExpressions(Collections.singletonMap(TOPIC, filterExpression))
    .setMessageListener(messageView -> {
        return ConsumeResult.SUCCESS;
    })
    .build();

擴容與遷移

擴容

如果想要在執行過程中的叢集擴容一臺 Broker，就需要將所有的後設資料都同步到這臺新的 Broker 上，ACL 2.0 提供了相應的複製使用者和複製授權的介面來支援這項操作。

介面定義

使用案例

# 複製使用者
sh mqadmin copyUser -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911
# 複製授權
sh mqadmin copyAcl -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911

遷移

如果已經使用上了 ACL 1.0，想要無縫地遷移至 ACL 2.0，也提供了相應的解決方案，只需要做以下配置即可。

配置定義

在 Broker 的配置檔案中開啟以下配置：

migrateAuthFromV1Enabled = true

特別說明

啟用以上配置後，將在 Broker 啟動過程中自動觸發執行。該遷移功能會把 ACL 1.0 中的使用者許可權資訊寫入 ACL 2.0 的相應儲存結構中。對於在 ACL 2.0 中尚未存在的使用者和許可權，系統將自動新增。對於已存在的使用者和許可權，遷移功能不會進行覆蓋，以避免重寫 ACL 2.0 中已經進行的任何修改。ACL 1.0 中關於 IP 白名單，由於是用於繞過訪問控制的檢查，和 ACL 2.0 的行為不匹配，所以不會遷移到 ACL 2.0 中。如果已經使用相關的能力，請完成改造後再做遷移。

規劃與總結

規劃

關於 RocketMQ ACL 的未來規劃，可能會體現在以下兩個方面：

• 豐富的認證和授權擴充套件：市場上存在豐富的認證和授權解決方案，其他的儲存或計算產品也都採用了各種各樣的實現方式。為了緊跟行業的發展趨勢，RocketMQ ACL 未來也將努力創新，以滿足更為廣泛和多變的客戶需求。同時，也將持續深化研究和發展更加出色的認證和授權策略，以達到安全性和效能之間的理想平衡。
• 視覺化的使用者許可權操作：當前，在 ACL 中進行使用者和許可權的配置僅能透過命令列工具，不夠友好。未來我們希望能在 RocketMQ Dashboard 上提供一個清晰、易用的視覺化管理介面，從而簡化配置流程並降低管理的技術門檻。另一方面，現有的 Dashboard 尚未整合 ACL 訪問控制體系，後續也要將它納入進來，以實現使用者在 Dashboard 上對各項資源進行操作的訪問許可權。

總結

RocketMQ ACL 2.0 不管是在模型設計、可擴充套件性方面，還是安全性和效能方面都進行了全新的升級。旨在能夠為使用者提供精細化的訪問控制，同時，簡化許可權的配置流程。歡迎大家嘗試體驗新版本，並應用在生產環境中。非常期待大家的在社群中反饋、討論，和參與貢獻，共同推進 RocketMQ 社群的成長和技術進步。

相關連結：

[1] RocketMQ 中文學習網站

ttps://http://rocketmq-learning.com

[2] 雲訊息佇列 RocketMQ

https://www.aliyun.com/product/rocketmq

作者：徒鍾

原文連結

本文為阿里雲原創內容，未經允許不得轉載。