GitHub user yhay81 added a comment to the discussion: ACL2.0 现在订阅组也需要鉴权了，如果是 ACL1.0 升级到 2.0 怎样保证兼容性呢？
不建议直接把现网 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，例如： ```bash 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 的兼容与迁移步骤](https://github.com/apache/rocketmq/issues/7560#issue-1995268627) - [ACL 2.0 官方文档（Topic + Group 的 Sub 示例）](https://rocketmq.apache.org/zh/docs/bestPractice/06access/) - [版本说明：5.3.0 引入 ACL 2.0，5.3.3 删除 ACL 1.0](https://rocketmq.apache.org/docs/security/01security/) GitHub link: https://github.com/apache/rocketmq/discussions/10660#discussioncomment-17772533 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
