Redis ACL 按命令类别限制应用权限的配置

我第一次把 Redis 应用账号从“能连上就什么都能做”收紧时，最容易写错的不是密码，而是命令类别和键范围。比较稳妥的做法是：先用 ACL CAT 看当前实例的类别，再从一个重置后的用户开始，只开放业务需要的类别和键前缀，最后用 ACL GETUSER 复查结果。

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

命令类别适合减少逐条列命令的工作量，但最小权限仍然要靠“命令类别 + 单项排除 + 键模式”一起完成。不要直接把 +@all 当成应用账号的默认权限。

先看 ACL CAT，不要猜类别里有什么

Redis ACL 可以用 +@category 一次加入一个命令类别，也可以用 -@category 排除它。类别不是固定的业务角色名，具体命令归属应以目标实例返回的结果为准。

# 查看当前 Redis 支持的 ACL 类别
redis-cli ACL CAT

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

# 查看管理类命令，确认应用账号不应接触的范围
redis-cli ACL CAT admin

ACL CAT 不带参数返回类别名称，带类别名时返回该类别包含的命令。一个命令可能属于多个类别，所以不要把类别理解成互斥分组；例如一个读写混合场景仍需要按实际调用补充或排除单个命令。

从 reset 开始创建应用用户

下面的例子假设应用只使用 cache:* 键，既需要读取也需要写入字符串和哈希数据。reset 放在前面，是为了清掉这个用户名过去可能留下的规则；之后再按从左到右的顺序写入新的规则。

# reset 清理旧规则，避免同名用户遗留权限
redis-cli ACL SETUSER app-cache reset \
  on >change-this-password \
  ~cache:* \
  +@read +@write

# 读取最终用户规则，确认用户状态、键模式和命令范围
redis-cli ACL GETUSER app-cache

on 允许用户认证，密码规则使用 > 加密码，~cache:* 限制可访问的键，+@read +@write 加入读写类别。生产环境应通过安全的凭据注入方式提供密码，示例里的密码只是占位符。

如果应用实际只读，可以把授权改成 +@read，不要为了省事保留 +@write。如果只用字符串命令，也可以从类别授权改为 +get +mget +set 这类单命令清单，让权限边界更容易审阅。

用减法规则处理高风险和模块边界

有些团队会先写 +@all，再逐个删除危险命令。这种写法虽然短，但应用账号会先获得所有命令；而且 Redis 官方文档特别提醒，除 +@all 外，其他类别通常不包含模块命令。我的经验是应用账号优先采用正向的窄授权，只有确实需要时才使用减法规则。

# 只有在确实需要“全量基础命令”时，才显式排除高风险类别
redis-cli ACL SETUSER app-cache reset \
  on >change-this-password \
  ~cache:* \
  +@all -@admin -@dangerous

# 更推荐：从读写类别开始，再按调用补充单个命令
redis-cli ACL SETUSER app-cache reset \
  on >change-this-password \
  ~cache:* \
  +@read +@write -config -flushall -flushdb

第二种写法更符合最小权限，但仍要注意类别会随 Redis 版本和模块环境变化。对模块命令、脚本命令或管理操作，应先在目标实例用 ACL CAT 和业务调用清单确认，再决定是否单独授权。

最后用 GETUSER 和 LIST 复查，而不是只看 OK

ACL SETUSER 返回 OK，只能说明规则命令被接受。再次调用同名用户时，规则默认是增量应用，不会自动重置。因此排查“权限怎么还在”时，先读出最终状态：

# 查看单个用户的 flags、密码、命令和键模式
redis-cli ACL GETUSER app-cache

# 查看服务器当前全部用户的可保存规则表示
redis-cli ACL LIST

# 需要持久化到 ACL 文件时，再按部署方式执行保存
redis-cli ACL SAVE

复查时重点看三件事：用户是否为 on，键模式是否只覆盖业务前缀，命令规则里是否混入了 +@all、+@admin 或不必要的危险命令。若修改了外部 ACL 文件而不是通过命令修改，需要按部署方式使用 ACL LOAD 重新加载。

常见问题

为什么给了 +@read，应用还是不能访问某个键？

命令类别只决定命令权限，键还要同时匹配用户的键模式。检查是否配置了正确的 ~cache:*，以及应用实际访问的键名是否带有不同前缀。

为什么重复执行 ACL SETUSER 后旧权限没有消失？

同名用户的后续调用默认是增量修改。需要重新定义完整边界时，把 reset 作为第一条规则，随后再写入新的认证、键和命令规则。

类别授权能覆盖 Redis 模块命令吗？

不要默认这样假设。官方文档说明普通类别通常不含模块命令；先在目标实例查看类别和模块命令，再按实际需要单独授权。

这套配置的核心不是记住一长串 ACL 语法，而是把应用身份、命令类别和键前缀同时收窄，并把最终规则读出来复查。这样 Redis 连接即使被错误使用，也较难越过应用本来不需要的管理和危险操作边界。