Redis ACL CAT 组合权限分类的配置方法

Redis ACL CAT 的作用不是直接替用户生成一条完整权限策略，而是先把当前服务器支持的 ACL 分类和分类内命令列出来。实际配置时，推荐把它当成“权限盘点入口”：先确认分类，再用 +@分类、-@分类 和少量单命令组合，最后用 key 模式限制访问范围。

官方地址：https://redis.io/docs/latest/

如果账号只服务于缓存读写，优先从 +@read 或 +@write 这样的分类开始，再按业务补充单命令并排除不需要的危险分类；不要一上来使用 +@all。

ACL CAT 先解决什么问题

Redis 的 ACL 分类是命令集合的标签，例如 read、write、string、stream、admin 和 dangerous。一个命令可能同时属于多个分类，所以分类不是互斥的菜单。ACL CAT 有两种核心用法：

• ACL CAT：列出服务器可用的分类名称。
• ACL CAT read：列出 read 分类中的命令。

官方文档将该命令标为 Redis Open Source 6.0.0 引入，复杂度为 O(1)，因为分类和命令集合由服务器维护。不同版本或加载的模块可能让分类清单出现差异，因此策略文件不要只凭旧文章里的分类列表硬编码。

先盘点分类，再决定授权方式

配置账号前可以先执行下面的盘点命令。示例使用 shell 注释说明每一步用途；命令输出本身没有被当作文章中的运行证据。

# 查看当前 Redis 实例支持的 ACL 分类
redis-cli ACL CAT

# 查看读写分类分别包含哪些命令
redis-cli ACL CAT read
redis-cli ACL CAT write

# 查看需要重点评估的管理和危险命令集合
redis-cli ACL CAT admin
redis-cli ACL CAT dangerous

如果业务只操作字符串缓存，不要因为看到了 read 和 write 就默认它可以操作所有数据类型。可以再用 ACL CAT string 检查字符串相关命令，并把结果与业务代码实际使用的命令清单对照。

三种组合方式怎么选

ACL 权限规则按传入顺序从左到右应用，重复调用 ACL SETUSER 也是在现有用户上增量修改，不会自动把用户重置。常见做法可以这样比较：

工程上通常采用混合方式：用分类表达主要职责，用单命令补齐一个明确的例外，再用负分类或负命令收紧范围。分类适合表达“这一类能力”，逐条命令适合表达“只有这一项例外”。

缓存读写账号的配置顺序

下面给出一个只操作 cache:* 键空间的账号示例。它展示的是配置顺序，不包含真实密码；生产环境应使用安全的密钥分发方式，并根据实际命令清单调整规则。

# 创建或更新缓存账号：先启用，再限定 key 范围
redis-cli ACL SETUSER cache-app on '~cache:*'

# 给予读写分类，再显式排除危险分类
redis-cli ACL SETUSER cache-app '+@read' '+@write' '-@dangerous'

# 业务只额外需要一个连接探活命令时，单独补充它
redis-cli ACL SETUSER cache-app '+PING'

# 让账号使用密码认证；示例密码仅为占位文本
redis-cli ACL SETUSER cache-app '>replace-with-secret'

# 将当前 ACL 配置写入外部 ACL 文件（按部署方式选择）
redis-cli ACL SAVE

这里的顺序有两个要点。第一，规则是累加的，后续调用不会替换前面的权限；第二，~cache:* 只限制 key 模式，不等于限制命令，所以命令分类和 key 范围要分别设计。若账号还需要访问 Pub/Sub，Redis 6.2 及以上还要单独考虑 channel 权限。

为什么不建议直接使用 +@all

+@all 会包含服务器当前存在的命令，也包含未来通过模块加载的命令；而普通分类通常不包含模块命令。它可以用于受控的管理账号，但不适合作为普通业务账号的默认起点。

如果确实需要“几乎全部能力，但排除危险操作”，官方 ACL 文档展示的思路是先允许全部，再减去危险分类。即使如此，也要明确这是一个高权限策略，并在模块安装、Redis 升级和权限变更时重新评估。对于缓存应用，+@read +@write -@dangerous 通常比 +@all 更容易说明意图，但仍应根据业务实际命令做收窄。

用 ACL LIST 与 ACL DRYRUN 复核

配置完成后，先查看 Redis 保存的规则表达式，再用模拟执行检查允许和拒绝的边界。ACL DRYRUN 用于模拟用户执行命令，不会真正执行命令，适合把它放进发布前的权限检查脚本。

# 查看用户最终被 Redis 解析后的 ACL 规则
redis-cli ACL LIST | grep 'user cache-app'

# 模拟正常读写命令，确认它们落在允许范围内
redis-cli ACL DRYRUN cache-app GET cache:demo
redis-cli ACL DRYRUN cache-app SET cache:demo value

# 模拟越界 key，确认 key 模式会阻止访问
redis-cli ACL DRYRUN cache-app GET other:demo

# 模拟高风险管理命令，确认危险分类没有被意外放开
redis-cli ACL DRYRUN cache-app CONFIG GET '*'

复核时重点看三类结果：业务需要的命令是否允许、非业务 key 是否被拒绝、管理或危险命令是否仍然可用。不要只看 ACL CAT 的分类名称，也不要只看 ACL LIST 的一行文本；两者分别回答“分类里有什么”和“用户最终拿到了什么”。

配置决策表

常见问题

ACL CAT 查不到业务模块命令怎么办？

先确认模块是否已经加载以及当前 Redis 版本支持的分类范围。普通分类不一定包含模块命令；不要把一次实例上的分类清单直接当作所有环境的固定清单。

多次执行 ACL SETUSER 会不会清空旧权限？

不会。已存在的用户会继续应用新规则，只有未知用户第一次创建时才从零权限开始。要重做策略，应明确执行重置规则或删除后重新创建，并在变更后查看 ACL LIST。

分类和单命令同时出现时谁优先？

规则按顺序增量处理，后面的允许或排除会改变前面的结果。因此把最终策略写成有顺序的配置片段，并用 ACL DRYRUN 覆盖关键允许和拒绝场景，比只背分类名称更可靠。

总结一下：ACL CAT 负责认识当前实例的权限分类，ACL SETUSER 负责把分类和单命令组合成用户策略，key 模式负责限制数据范围。先盘点、再组合、后复核，通常比直接给业务账号 +@all 更容易维护。