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 提供了用戶的啓用與禁用功能。當發生安全事件，可以通過禁用用戶狀態，快速進行止血，從而達到阻止非法訪問的目的。

認證流程

客戶端流程：

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

服務端流程：

服務端接收到請求後，首先檢查是否開啓認證，若未開啓，則不校驗直接通過；若已開啓了，則進入下一步。
服務端對請求進行認證相關的參數進行解析和組裝，獲取包括用戶名和 Signature 等信息。
通過用戶名在本地庫中查詢用戶相關信息，用戶不存在，則返回處理無；用戶存在，則進入下一步。
獲取用戶密碼，採用相同的加密算法對請求進行加密生成 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 訪問控制，爲系統的安全性增添一道堅實的防線。

授權流程

客戶端流程：

客戶端在構建 RPC請求時，構建本次調用的接口入參，接口對應權限背後的操作定義。
客戶端在接口入參中設置本次訪問的資源信息，然後將用戶和資源等參數傳遞到服務端。

服務端流程：

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

授權參數的解析

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

硬編碼方式解析

對於消息發送和消費這類接口，參數相對較爲複雜，且請求頻次也相對較高。考慮到解析的便捷性和性能上的要求，採用硬編碼的方式進行解析。

註解方式解析

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

權限策略優先級

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

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

認證授權策略

出於安全和性能的權衡和考慮，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 社區的成長和技術進步。歡迎加入 Apache RocketMQ 中國開發者釘釘羣。（羣號：21982288）

相關鏈接：

[1] RocketMQ 中文學習網站 ttps://rocketmq-learning.com

[2] 雲消息隊列 RocketMQhttps://www.aliyun.com/product/rocketmq