(架构实战)你的RocketMQ集群是安全的吗?
RocketMQ是一款非常优秀的主流中间件,本文是RocketMQ系列的第52篇文章,重点阐述笔者在公司升级RocketMQ集群并开启ACL的真实经历,并且遇到的一些问题及其解决方案,实战性非常强。
1、ACL机制的重要性
某一天突然接到安全团队的通知,公司内网部署的RocketMQ集群安全性非常低,需要立马整改。
接到安全团队的通知,马上开启了复盘,公司内部的RocketMQ集群还是基于RocketMQ4.1搭建的,存在重大安全隐患,因为生产环境的任意一台机器,不需要知道RocketMQ集群所在机器的密码,就能拥有最高的控制权,说明如下:
试想一下,如果在生产环境任意一台机器上部署一个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校验机制,其策略概况如下:
- 对于需要admin权限的操作,服务端必须开启校验。
- 对于不需要admin权限的操作,例如消息的发送、消费,如果客户端没有上传校验信息,默认放行
基于上述这样的改造,暂时可以解决问题。
RocketMQ的acl校验器是基于SPI机制,可插拔,提供了org.apache.rocketmq.acl.AccessValidator接口,并且需要将具体实现类写入到broker/src/main/resources/META-INF.service /org.apache.rocketmq.acl. AccessValidat or文件中。
但需要注意的是,如果该文件中配置了多个校验器,会自动组装成链条。
在实际使用过程中,发现这种扩展机制从使用层面来看并不优好,校验器(策略)尽量参数化,即在broker中使用参数来指定。
文章转载自公众号: 中间件兴趣圈