ACL2.0 现在订阅组也需要鉴权了，如果是 ACL1.0 升级到 2.0 怎样保证兼容性呢？

[humkum]

ACL1.0 对订阅组资源没有进行鉴权，仅对 topic 判断是否有读写权限。ACL2.0 开启后，订阅组心跳都需要鉴权了，升级的兼容性社区有什么好的实践吗？

[yhay81]

不建议直接把现网 Broker 一次性切到 ACL 2.0。这里需要把“版本升级”和“鉴权模型切换”拆成两个阶段；ACL 2.0 不会自动把 ACL 1.0 中缺失的 Group 权限推断出来。

一个比较稳妥的流程是：

1. 先使用同时支持 1.0/2.0 的过渡版本。 在 Broker 配置中显式设置 rocketmq.acl.version=1.0，再升级二进制。ACL 2.0 从 5.3.0 引入，而 5.3.3 已删除 ACL 1.0，所以迁移窗口应停在 5.3.0～5.3.2，不能从 ACL 1.0 直接跳到 5.3.3。官方 RIP 的迁移顺序也是先以 1.0 模式升级、迁移数据、最后再切 2.0。

2. 盘点 AccessKey 与实际资源的对应关系。 对每个消费者列出它访问的全部 Topic 和实际 consumerGroup（包括不同环境、临时任务、Console/运维工具使用的组）。ACL 1.0 的 topicPerms 只能迁出 Topic 权限，Group 权限必须从客户端配置或运行清单补齐。

3. 在切换前创建 ACL 2.0 用户和策略。 消费者的 Sub 必须同时覆盖 Topic 和 Group，例如：

sh bin/mqadmin createAcl -n <namesrv> -c <cluster> \
  -s User:consumer_user \
  -r Topic:OrderTopic,Group:OrderConsumerGroup \
  -a Sub -d Allow

生产者只需相应 Topic 的 Pub；Console、监控和 mqadmin 则要按实际用途补 Cluster/Topic/Group 的 Get/List 等管理权限，不要给业务客户端复用超级用户。批量迁移后用 getAcl / listAcl 逐个核对，并确保配置已经落到集群内所有 Broker；有 Proxy 时也要验证经 Proxy 的收发链路。

4. 先做 canary，再滚动切换。 用每类真实客户端执行启动心跳、订阅、拉取/消费、重启和 rebalance 测试。确认没有 AUTHENTICATION / AUTHORIZATION 拒绝后，再逐台把 rocketmq.acl.version 改为 2.0 并重启。混合阶段要求同一套 AccessKey/Secret 在两套配置中都有效。

5. 保留可回滚点。 保留 ACL 1.0 文件备份和过渡版本；发现遗漏时可把该 Broker 切回 1.0。ACL 2.0 稳定运行一段时间后，才继续升级到 5.3.3+，因为到那时已经不能只改配置回退到 1.0。

另外，ACL 1.0 的全局 IP 白名单不能原样迁移。需要改成 ACL 2.0 策略上的 sourceIps（mqadmin 的 -i）或网络层白名单，不能误以为原来的 bypass 仍然生效。

参考：

• RIP-68 的兼容与迁移步骤
• ACL 2.0 官方文档（Topic + Group 的 Sub 示例）
• 版本说明：5.3.0 引入 ACL 2.0，5.3.3 删除 ACL 1.0