一. 概述

权限控制（ACL）主要为 RocketMQ 提供 Topic 资源级别的用户访问控制。这里主要两个限制用户访问控制：

• 签名验证，主要是对请求进行签名验证，这里涉及到的是 AccessKey 和 SecretKey。

• 资源权限的校验；主要是对某些资源进行限制用户访问，主要是基于 topic 和 group 进行资源管控，可以重点 PlainAccessValidator.parse 对其资源的封装；

同时也提供了白名单这个特性，其优先级比上面的要高。白名单有全局白名单，也有局部白名单。

• 白名单，如果客户端是在白名单的，则一律放行，不再进行限制用户策略校验；

用户在使用 RocketMQ 权限控制时，可以在 Client 客户端通过 RPCHook 注入 AccessKey 和 SecretKey 签名；在 Broker 端配置/设置相关的事项，如资源权限控制属性（包括 Topic 访问权限、IP 白名单和 AccessKey 和 SecretKey 签名等）。

Broker 端对 AccessKey 所拥有的权限进行校验，校验不过，抛出异常。

二. 权限控制流程

权限控制流程主要在 PlainPermissionManager 的 parse 和 validate 方法中；流程如下

三. 配置

这里的配置是指为了能使用 ACL，我们要做哪些配置工作；

3.1 Broker 端

Broker 端有两种方式去：

• Broker 端启动加载配置文件，去做相关的初始化；

• 通过接口动态配置相关的信息

但前提是得打开 ACL 安全特性，通过修改

• aclEnable 默认是不使用 ACL 特性的

3.1.1 启动初始化

启动时，会默认加载{RocketMQ_HOME}/conf/plain_acl.yml 的文件；其文件的内容格式如下：

//白名单globalWhiteRemoteAddresses: - 10.10.103.*- 192.168.0.*
//accounts的配置accounts:- accessKey: RocketMQ  secretKey: 12345678  whiteRemoteAddress:  //是否是管理者，如果是管理者，则不需要校验其资源权限；  admin: false   // 默认的topic权限，有四个值供填，  //DENY	拒绝  //ANY	PUB 或者 SUB 权限	//PUB	发送权限	//SUB 订阅权限  defaultTopicPerm: DENY   //默认的组权限  defaultGroupPerm: SUB  // topic的权限  topicPerms:  - topicA=DENY  - topicB=PUB|SUB  - topicC=SUB  //组权限  groupPerms:  - groupA=DENY  - groupB=PUB|SUB  - groupC=SUB
- accessKey: rocketmq2 	// .....

3.1.2 动态配置

通过发送如下接口可以动态的更新其配置信息：

• UPDATE_AND_CREATE_ACL_CONFIG 添加或更新 AccessKey 对应的 PlainAccessResource 对象信息

• DELETE_ACL_CONFIG 删除 AccessKey 对应的 PlainAccessResource 对象信息

• GET_BROKER_CLUSTER_ACL_CONFIG 获取 acl 配置信息，也就是 plain_acl.yml 内容。

• GET_BROKER_CLUSTER_ACL_INFO 获取 Broker 集群 ACL 版本信息

• UPDATE_GLOBAL_WHITE_ADDRS_CONFIG 更新全局白名单，这里是全量的，也就是直接覆盖之前的白名单；

这里不要频繁调用其接口去做更改，会影响 Broker 性能；

3.2 Client 端

在客户端就相对于比较简单；直接在创建生产者或消费者对象时，传入 AclClientRPCHook 对象即可；

该 AclClientRPCHook 需要 SessionCredentials 对象，传入 AccessKey 以及 SecretKey 即可，至于 securityToken 目前没有发现其有任何作用；

四. 总结

ACL 权限相对于比较简单，但要注意的是，Master/Slave 和 Dledger 模式的架构时，直接添加白名单来忽略 ACL 校验；