What’s New in RocketMQ ACL 2.0? A Deep Dive into Features, Architecture, and Configuration

RocketMQ is a widely used distributed messaging middleware, but its original ACL 1.0 version has several security shortcomings that limit its suitability for large‑scale, cloud‑native deployments. To address these issues, RocketMQ ACL 2.0 introduces a comprehensive upgrade that enhances data protection, access control granularity, and operational flexibility.

Background and Pain Points of ACL 1.0

IP whitelist was misused to bypass authentication, creating security risks in public‑network scenarios.

Only 9 out of more than 130 management APIs were protected, leaving many operations vulnerable.

Cluster components (NameServer, Broker, Proxy) lacked mutual authentication, allowing rogue nodes to access sensitive data.

Key Features of ACL 2.0

Fine‑grained API resource permissions: All resources (cluster, namespace, topic, consumer group) and every API are now subject to permission checks.

Multiple matching modes: Literal, prefix, and wildcard matching simplify policy definition for large resource sets.

Cluster‑wide component access control: Leader election, data replication, and Proxy‑to‑Broker interactions are all authorized.

Separation of authentication and authorization: Enables flexible deployment scenarios such as "authentication only".

Security‑performance balance: Provides both stateless (per‑request) and stateful (session‑based) strategies.

Pluggable architecture: Allows future extensions for new authentication or authorization mechanisms.

Access Control Model

ACL 2.0 combines Role‑Based Access Control (RBAC) and Attribute‑Based Access Control (ABAC). Super users have unrestricted access, while normal users must be granted explicit permissions based on attributes such as user, resource, operation, and source IP.

Authentication Flow

Client builds an RPC request; if credentials are configured, it signs the request using AK/SK.

The request includes the username and signature.

Server checks whether authentication is enabled; if not, the request passes.

If enabled, the server retrieves the stored password, recomputes the signature, and compares it to the client’s signature.

Matching signatures result in successful authentication.

Authorization Flow

Server verifies whether authorization is enabled.

It extracts user, resource, operation, and environment information from the request.

For super users, the request is allowed immediately.

For normal users, the server fetches applicable policies, matches them against the request, and selects the highest‑priority policy.

The decision (allow or deny) is returned to the client.

Policy Priority

When multiple policies match a resource, ACL 2.0 resolves conflicts using a defined priority order (explicit deny > explicit allow > default). Diagrams illustrate how overlapping policies are evaluated.

Configuration and Deployment

Two deployment modes are supported:

Integrated compute‑storage (Broker‑only): Broker handles both data storage and request processing, including authentication and authorization.

Separated compute‑storage: Proxy handles client requests, while Broker stores metadata; Proxy performs auth checks using metadata from Broker.

Configuration snippets show how to enable authentication and authorization on both Broker and Proxy, including parameters such as authenticationEnabled = true, authorizationEnabled = true, and provider class names.

Command‑Line Management

Examples demonstrate user management ( mqadmin createUser, updateUser, deleteUser, etc.) and ACL management ( mqadmin createAcl, updateAcl, listAcl, etc.).

Client Usage

Java code snippets illustrate how to configure a producer or consumer with AK/SK credentials using the RocketMQ client API.

Scaling, Migration, and Future Plans

Scaling: mqadmin copyUser and copyAcl help replicate users and policies to new brokers.

Migration: Setting migrateAuthFromV1Enabled = true automatically migrates ACL 1.0 data to the new format, excluding IP‑whitelist rules.

Future work includes richer authentication/authorization extensions, visual management via RocketMQ Dashboard, and continued balance between security and performance.

Audit Logging

Both authentication and authorization events are logged with clear messages, e.g.,

[AUTHENTICATION] User:rocketmq is authenticated success with Signature = ...

and

[AUTHORIZATION] Subject = User:rocketmq is Allow Action = Pub ...

.

Overall, RocketMQ ACL 2.0 delivers a modern, extensible, and secure access control framework suitable for cloud‑native environments.