Skip to content

RIP-77: Deprecate and Remove ACL 1.0 #9362

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dingshuangxi888 opened this issue Apr 24, 2025 · 2 comments · May be fixed by #9363
Open

RIP-77: Deprecate and Remove ACL 1.0 #9362

dingshuangxi888 opened this issue Apr 24, 2025 · 2 comments · May be fixed by #9363

Comments

@dingshuangxi888
Copy link
Contributor

dingshuangxi888 commented Apr 24, 2025

Status


Background & Motivation

What do we need to do

  • Will we add a new module? No.

  • Will we add new APIs? No.

  • Will we add a new feature? No.

  • 是否会新增模块? 不会。

  • 是否会新增API? 不会。

  • 是否会新增新特性? 不会。

Why should we do that

Are there any problems with our current project?

Yes. ACL 1.0 has the following major issues:

  • IP whitelist can bypass authentication: In ACL 1.0, the IP whitelist is used to bypass authentication, which deviates from security best practices. In scenarios where public IPs are shared, it can easily lead to unauthorized access and data leakage.
  • Lack of fine-grained API control: ACL 1.0 only supports a very small number of management APIs for permission control and cannot cover all sensitive operations, increasing risks of attacks and data manipulation.
  • No access control among components: There is a lack of permission checks between key components within the cluster, which poses risks of forged components joining the cluster and accessing sensitive data.

是的,ACL 1.0 存在以下主要问题:

  • IP白名单可绕过鉴权: ACL 1.0 使用 IP 白名单作为绕过鉴权的手段,偏离安全最佳实践,在公网共享 IP 场景下易导致未授权访问和数据泄露风险。
  • 缺乏API精细化管控: ACL 1.0 仅支持极少数管理 API 的权限控制,无法覆盖所有敏感操作,增加系统被攻击和数据被非法操作的风险。
  • 组件间无访问控制: 集群内部关键组件间缺乏权限校验,存在伪造组件接入集群、非法访问数据等安全隐患。

What can we benefit from proposed changes?

  • Eliminate security risks and improve system security and compliance.

  • Reduce maintenance costs and avoid relying on insecure and outdated permission models.

  • Encourage users to migrate to the more secure and feature-rich ACL 2.0.

  • 消除安全隐患,提升系统安全性和合规性。

  • 降低维护成本,避免依赖不安全、设计落后的权限模型。

  • 推动用户迁移到更安全、功能更完善的 ACL 2.0。


Goals

  • What problem is this proposal designed to solve?
    • Address the security and maintenance issues of ACL 1.0 and prevent unauthorized access and sensitive data leakage.

    • Ensure consistency, maintainability, and scalability of RocketMQ’s permission management solution.

    • Provide a smooth migration path to help users transition from ACL 1.0 to ACL 2.0.

    • 解决 ACL 1.0 存在的安全和运维隐患,防止未授权访问和敏感数据泄露。

    • 保证 RocketMQ 权限管理方案的一致性、可维护性和可扩展性。

    • 提供平滑的迁移路径,确保用户能方便地从 ACL 1.0 过渡到 ACL 2.0。


Non-Goals

  • What problem is this proposal NOT designed to solve?
    • It does not introduce new permission features or interfaces.

    • It does not extend the permission model beyond ACL 2.0.

    • It does not address features unrelated to ACL 1.0.

    • 不涉及新增权限特性或接口。

    • 不涉及对 ACL 2.0 以外的权限模型扩展。

    • 不关注与 ACL 1.0 无关的其他 RocketMQ 功能。


Changes

Architecture

  • Remove the rocketmq-acl module and all ACL 1.0 related configuration items and admin tools.

  • Migrate all ACL-related classes in the client to the rocketmq-client module.

  • Retain the migration capability from ACL 1.0 to 2.0 in ACL 2.0.

  • 移除 rocketmq-acl 模块及所有 ACL 1.0 配置项和 admin 工具。

  • 客户端中涉及 ACL 的相关类全部迁移至 rocketmq-client 模块。

  • 在 ACL 2.0 中保留从 ACL 1.0 到 2.0 的迁移能力。

Interface Design/Change

  • No new APIs will be added and existing ACL 2.0 APIs remain unchanged.

  • Remove all ACL 1.0 related configuration items and interfaces.

  • 不新增 API,不变更现有 ACL 2.0 API。

  • 移除所有 ACL 1.0 相关配置项和接口。

Implementation

  • Remove the rocketmq-acl module and related code.

  • Remove ACL 1.0 configuration items and admin tool implementations.

  • Migrate client-side ACL-dependent classes to the rocketmq-client module.

  • Retain the migration feature in ACL 2.0 (migrateAuthFromV1Enabled = true).

  • 删除 rocketmq-acl 模块相关代码。

  • 移除 ACL 1.0 配置项及 admin 工具实现。

  • 客户端相关 ACL 依赖类迁移到 rocketmq-client 模块。

  • 在 ACL 2.0 中保留 migrateAuthFromV1Enabled = true 的迁移能力。


Compatibility, Deprecation, and Migration Plan

Are backward and forward compatibility taken into consideration?

  • After ACL 1.0 is deprecated, old ACL 1.0 configurations and interfaces will no longer be supported.

  • ACL 2.0 is fully compatible with clients and requires no additional adaptation.

  • ACL 1.0 下线后,不再兼容旧有的 ACL 1.0 配置与接口。

  • ACL 2.0 完全兼容客户端,无需额外适配。

Are there deprecated APIs?

  • All ACL 1.0 related configuration items, interfaces, and tools will be deprecated and removed.

  • 所有 ACL 1.0 相关配置项、接口和工具将被废弃并移除。

How do we do migration?

Server-side Migration

  • Set migrateAuthFromV1Enabled = true in the Broker configuration file. When the Broker starts, it will automatically migrate user permission information from ACL 1.0 to ACL 2.0.

  • For users and permissions that do not exist in ACL 2.0, the system will automatically add them; for those that already exist, migration will not overwrite them, avoiding any modification to customized settings.

  • The IP whitelist mechanism in ACL 1.0 will not be migrated to ACL 2.0. If there is a dependency, please complete the necessary adaptation before migration.

  • After migration, check the integrity and validity of ACL 2.0 permission configurations, and fully verify system availability in the test environment.

  • 在 Broker 配置文件中设置 migrateAuthFromV1Enabled = true,Broker 启动时会自动将 ACL 1.0 的用户权限信息迁移到 ACL 2.0 的存储结构中。

  • 对于 ACL 2.0 中尚未存在的用户和权限,系统会自动添加;对于已存在的用户和权限,迁移过程不会覆盖,避免影响已做的个性化修改。

  • ACL 1.0 的 IP 白名单机制不会迁移到 ACL 2.0。如有依赖,请在迁移前完成相关改造。

  • 迁移完成后,请核查 ACL 2.0 权限配置的完整性和有效性,并在测试环境充分验证系统的可用性。

Client-side Changes

  • If the client does not upgrade the RocketMQ version, it can continue to use the current implementation without any changes.
  • If the client needs to upgrade to the latest version, remove the Maven dependency on the rocketmq-acl module, for example:
<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-acl</artifactId>
    <version>${rocketmq.version}</version>
</dependency>
  • ACL-related classes on the client side have been merged into the rocketmq-client module, so there is no need to rely on rocketmq-acl separately after the upgrade.

  • All automated scripts and console functions that depend on ACL 1.0 related configurations need to adapt to the ACL 2.0 interface.

  • 如果客户端不升级 RocketMQ 版本,可以继续使用当前实现,无需做任何改动。

  • 如果客户端需要升级到最新版本,请移除对 rocketmq-acl 模块的 Maven 依赖。例如:

<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-acl</artifactId>
    <version>${rocketmq.version}</version>
</dependency>
  • 客户端侧涉及 ACL 的相关类已合并至 rocketmq-client 模块,升级后无需再单独依赖 rocketmq-acl
  • 所有依赖 ACL 1.0 相关配置的自动化脚本和控制台功能,需要完成对 ACL 2.0 接口的适配。

Implementation Outline

  • Remove the rocketmq-acl module and related code.

  • Remove ACL 1.0 configuration items and admin tool implementations.

  • Migrate client-side ACL-dependent classes to the rocketmq-client module.

  • Retain the migration capability in ACL 2.0 (migrateAuthFromV1Enabled).

  • Update documentation and provide migration guidance, especially regarding IP whitelist and admin tool adaptation.

  • Release the new version and assist users in completing migration and upgrade verification.

  • 删除 rocketmq-acl 模块及相关代码。

  • 移除 ACL 1.0 配置项和 admin 工具实现。

  • 将客户端侧相关 ACL 依赖类迁移到 rocketmq-client 模块。

  • 保留 ACL 2.0 的迁移能力(migrateAuthFromV1Enabled)。

  • 更新文档,提供迁移指导,特别是 IP 白名单和 admin 工具适配说明。

  • 发布新版本,协助用户完成迁移和升级验证。

@francisoliverlee
Copy link
Member

nice of it. and users need how-to-migrate doc from ACL1.0 to ACL 2.0

@dingshuangxi888
Copy link
Contributor Author

dingshuangxi888 commented Apr 25, 2025 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants