RocketMQ生产环境部署必须将安全与权限配置作为上线刚性门槛，涵盖系统层最小权限、网络层端口收敛与IP白名单、ACL细粒度账号资源控制及Dashboard与客户端联动认证。
RocketMQ 生产环境部署必须把安全与权限配置当作上线前的刚性门槛，而不是“补丁式”收尾。裸奔的 Broker 暴露在公网或内网未隔离环境中，轻则被刷 Topic、盗消费，重则引发数据泄露甚至业务中断。真正有效的防护不是堆砌功能，而是从系统层、网络层、ACL 层到客户端层形成闭环控制。
操作系统与目录权限最小化
用 root 直接跑 Broker 是高危操作。应创建专用用户和组，并严格限定各目录权限：
- 创建 rocketmq 用户组和非登录用户：
groupadd rocketmq && useradd -g rocketmq -s /bin/false rocketmq -
/opt/rocketmq所属用户为 rocketmq:rocketmq，权限设为 750（禁止其他用户写入） -
/var/log/rocketmq同样属 rocketmq，权限 750，避免日志被篡改或注入 -
/etc/rocketmq配置目录由 root 管理，权限 644，确保只有管理员可修改 broker.conf 或 plain_acl.yml
网络层隔离与端口收敛
不能依赖 ACL 代替网络防火墙。NameServer 和 Broker 的监听端口必须按角色收敛并绑定可信网段：
- NameServer 默认端口 9876，只允许内部服务网段（如
192.168.10.0/24）访问 - Broker 客户端通信端口（10911）、VIP 通道端口（10909）同样限制来源 IP
- 使用
firewalld创建专属 zone，而非全局放行：firewall-cmd --permanent --new-zone=rocketmq，再逐条添加策略 - 禁用所有未声明端口，尤其关闭
10912（Broker HA 同步端口）对外暴露，仅用于主从节点间通信
ACL 权限模型与 plain_acl.yml 实战配置
ACL 不是开关，而是细粒度资源控制策略。关键在于三要素对齐：账号（accessKey/secretKey）、资源（Topic/Group）、动作（PUB/SUB/DENY）。配置需满足热加载且拒绝默认宽松：
- Broker 配置中启用：
aclEnable=true，并确保plain_acl.yml路径正确挂载（Docker 环境注意 volume 映射） - 全局白名单仅保留运维跳板机 IP：
globalWhiteRemoteAddresses: ["192.168.1.100"]，避免127.0.0.1泄露到生产配置 - 默认权限设为最严：
defaultTopicPerm: DENY、defaultGroupPerm: DENY，显式授权优于隐式放行 - 生产者账号示例：
accessKey: prod-pay+topicPerms: ["PAY_TOPIC:PUB"]，不配 groupPerms - 消费者账号示例：
accessKey: cons-order+groupPerms: ["ORDER_CONSUMER_GROUP:SUB"]，不配 topicPerms
Dashboard 与客户端侧安全联动
Dashboard 本身不是特权入口，但若未加固，会成为 ACL 绕过缺口。同时客户端必须同步认证信息，否则连接直接被拒：
- Dashboard 启动时指定独立配置文件，禁用默认 admin 登录；其后端需通过反向代理加 Basic Auth 或 JWT 校验
- Java 客户端必须设置
credentials：producer.setAccessKey("prod-pay")、producer.setSecretKey("xxx") - Spring Boot 应用推荐使用
rocketmq-spring-boot-starter并在application.yml中声明：rocketmq.access-key和rocketmq.secret-key - 务必验证 ACL 生效：用错误 accessKey 发送消息，应收到
NO_PERMISSION异常，而非超时或连接拒绝
