RocketMQ ACL 版本升级过程中的曲折经历 (大厂线上环境大规模 MQ 升级开启 ACL 实战)

1、ACL 机制的重要性

某一天突然接到安全团队的通知，公司内网部署的 RocketMQ 集群安全性非常低，需要立马整改。

接到安全团队的通知，马上开启了复盘，公司内部的 RocketMQ 集群还是基于 RocketMQ4.1 搭建的，存在重大安全隐患，因为生产环境的任意一台机器，不需要知道 RocketMQ 集群所在机器的密码，就能拥有最高的控制权，说明如下：

![在这里插入图片描述](https://img-blog.csdnimg.cn/20210509204158198.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

9ibG9nLmNzZG4ubmV0L3ByZXN0aWdlZGluZw==,size_16,color_FFFFFF,t_70#pic_center)

试想一下，如果在生产环境任意一台机器上部署一个 rocketmq-console，就可以通过 rocketmq-console 新增、删除 topic，其危害性非常之大，是不是后背发凉。

出现这个问题的本质原因：MQ 集群没有开启授权访问。

2、迎来曙光

为了解决上述重大安全问题，RocketMQ 官方在 4.4.0 版本引入了 ACL,提供访问控制，客户端在创建 TOPIC、发送消息、消息消息时首先会判断该客户端是否拥有权限，安全性得到增强。

关于如何搭建 ACL 已在 ACL使用详解已有详细介绍，本文不做详细介绍，本文主要是阐述从 4.1.0 版本升级到 4.8.0 之后，开启 ACL 的可行性研究。

在升级之前，公司几千个应用客户端使用的是 4.1.0 版本，升级成 4.8.0 并开启 ACL，我们需要重点验证其兼容性。升级后的部署架构如下图所示：

主要几个测试用例：

• 客户端不开启 ACL，服务端开启 ACL

• 客户端开启 ACL，服务端不开启 ACL

在进一步深入讲解这些用例把背后的的诉求前，说明一下客户端开启 ACL 是指在构建消息发送者、消息消费者时，传入与 ACL 相关的参数，截图如下：

接下来逐步分析上述测试用例的目的。

2.1 客户端不开启 ACL，服务端开启 ACL

例如像我们公司的技术架构，涉及到数据的流转，重度依赖 MQ，目前应用中存在太多的低版本的 MQ 客户端，例如 4.1.0，如果服务端开启了 ACL，如果能兼容低版本客户端，那这样升级起来就会显得非常容易，但经过测试：结果为不兼容。其实这个也好理解，服务端开启了 ACL，客户端没有授权信息，是肯定不会让你通过的。

2.2 客户端开启 ACL，服务端不开启 ACL

经过测试，服务端如果不开启 ACL 的话，尽管客户端在消息发送、消息消费等场景下发送了授权信息，但服务端会忽略这些信息，并不会触发 ACL 校验。

3、优雅升级与弊端

基于开源版本，通过上面的验证，其优雅升级思路：为各个客户端规划好用户名与密钥,并且对所有客户端进行改造，等待所有客户端都完成改造后，服务端再开启 ACL。

通常在具体实践中，由于涉及所有客户端改造，可以分集群进行改造，由上到下推动该事项的执行，统一定好一个客户端改造的最后时间点，在该时间点后，服务端开启 ACL，至此完成 RocketMQ 集群的授信访问。、

上述方案的缺点也是显而易见的，需要客户端先行改动，只有等所有客户端全部改造完成后，服务端才能开启 ACL。

4、自定义 ACL 校验器

由于当时项目的升级的迫切性，基于官方版本这种升级方案显然无法满足我们当时的需求。回到文章开头部分说的紧迫诉求：当务之急是要限制生产环境任意一台机器对 MQ 集群的管理权限,即限制对 MQ 中 topic、消费组的创建与删除，对 Broker 相关配置的修改。

为了解决上述问题，需要利用 RocketMQ 自定义的 ACL 校验机制，其策略概况如下：