Redis ACL DRYRUN 怎么预演用户权限而不执行命令

Redis ACL DRYRUN 用来回答一个很具体的问题：某个用户如果执行某条命令，按照当前 ACL 规则会被允许还是拒绝？它只做权限判断，不真正执行被测试的命令，因此适合放在权限调整、客户端切换和故障排查之前。返回 OK 表示权限判断通过；返回带原因的错误文本，则说明需要继续看用户状态、命令权限、键模式或命令参数。

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

官方命令文档：https://redis.io/docs/latest/commands/acl-dryrun/

• ACL DRYRUN username command [arg ...] 的第一个参数是被模拟的用户。
• 它检查命令与参数对应的权限，但不启用用户，也不产生真实读写副作用。
• 该命令从 Redis Open Source 7.0.0 起可用，旧版本不能按本文命令直接判断。

先分清预演和真实执行

权限排查中最危险的误区，是把“测试这条命令”写成“真的执行这条命令”。例如，想知道 app_reader 能否读取某个键时，直接执行 GET 可能会读取真实数据；测试写命令则可能改变业务状态。ACL DRYRUN 把被测用户、命令和参数作为判断输入，返回授权结论，但不会把被测命令送进真实执行路径。

这并不等于可以忽略命令参数。ACL 规则不只限制命令名称，还可能限制可访问的键模式；同一个用户执行 GET，面对不同键名时可能得到不同结论。因此预演时要把真实调用中的关键参数一并写入。

用最小命令判断允许还是拒绝

下面的例子只使用占位用户和键名。它是命令写法示意，不代表某个实例一定返回相同文本。

# 预演 app_reader 执行 GET；只判断权限，不读取真实键值
redis-cli --user admin --askpass ACL DRYRUN app_reader GET cache:demo

# 预演写入命令；参数也要带上，便于同时判断键模式
redis-cli --user admin --askpass ACL DRYRUN app_reader SET cache:demo value

# 预演需要多个参数的命令；按真实命令顺序传递参数
redis-cli --user admin --askpass ACL DRYRUN app_reader HGET user:demo name

如果预演结果是 OK，只能说明当前 ACL 规则允许这组“用户 + 命令 + 参数”。它不证明网络连接、数据库负载或应用序列化一定正常。反过来，如果结果是“用户没有权限运行某命令”之类的错误，也不要立刻执行 ACL SETUSER；先确定拒绝究竟来自命令权限、键模式还是用户本身处于禁用状态。

拒绝文本怎样定位原因

可以把一次拒绝拆成四个观察面：用户状态、命令权限、键模式和命令参数。先用 ACL GETUSER 查看目标用户，再根据预演命令的类型检查允许的命令或命令类别，最后确认测试键是否落在授权模式中。不要只看到用户存在，就认为它具备完整业务权限。

# 查看用户启用状态、命令规则和键模式；输出中的密码字段不要写入工单
redis-cli --user admin --askpass ACL GETUSER app_reader

# 只做权限预演；将拒绝结果与上面的用户规则逐项对照
redis-cli --user admin --askpass ACL DRYRUN app_reader GET cache:demo

例如，用户可能被允许执行读取类命令，却只允许访问 ~cache:*；此时预演 GET cache:demo 与预演 GET order:demo 的结论可以不同。还有一种常见情况是命令本身允许，但参数组合触发了更细的权限限制。拒绝文本是定位线索，不是修改权限的授权书。

把预演变成权限发布前清单

权限变更前，可以为每个业务用户保存少量非敏感的预演用例：一个应当成功的读命令、一个应当拒绝的写命令，以及一个用于确认键模式边界的命令。每条用例记录用户名、命令、必要参数和预期结论，不记录密码、令牌或真实业务数据。

预演通过后，真实客户端仍需要在受控环境中做一次最小业务验收，因为 ACL DRYRUN 只回答授权判断，不检查连接池、超时、序列化和应用重试。把两类检查分开，才能知道失败是权限问题还是应用链路问题。

版本和客户端调用的边界

先确认 Redis 版本支持 ACL DRYRUN；官方文档标注该命令从 Redis Open Source 7.0.0 起可用。客户端没有专用方法时，可以通过协议层的通用命令调用能力传递 ACL、DRYRUN、用户名、命令和参数，但要遵守客户端自己的参数数组和响应解析规则。不要把返回的拒绝文本当作统一的业务错误码，应用侧应保留原始原因并做安全脱敏。

最小判断顺序可以记为：先看用户，再看命令，再看键模式，最后看参数。这样既能避免为了试错直接执行高风险命令，也能让 ACL 变更在上线前留下可重复的权限证据。

常见问题

ACL DRYRUN 会不会读取真实键值？

不会把被测命令作为真实业务操作执行。它用于模拟指定用户的权限判断，但预演参数仍应贴近真实调用，尤其是键名和多参数命令。

返回 OK 就代表应用一定能调用成功吗？

不代表。OK 只说明 ACL 判断通过，网络、连接池、超时、序列化和应用自身错误仍需要单独检查。

为什么同一个用户测试两个 GET 结果不同？

常见原因是键模式不同。ACL 可能允许读取某个前缀，却拒绝另一个前缀；应把实际键名作为参数传给 DRYRUN。

拒绝后能不能直接用 ACL SETUSER 修复？

不建议直接改。先用 ACL GETUSER 对照用户状态、命令权限和键模式，确认拒绝原因，再按权限最小化原则提交变更并重新预演。

本文参考 Redis 官方 ACL DRYRUN 文档，配图为原创静态结构说明图，不代表本机或线上 Redis 的执行截图。