Redis ACL DRYRUN 怎么在授权前测试一条命令

如果你想在正式启用 Redis ACL 用户前确认“一条具体命令能不能执行”，直接让有 ACL 管理权限的连接运行 ACL DRYRUN 用户名 命令 参数...。它会按该用户的 ACL 规则模拟权限判断：允许时返回 OK，不允许时返回原因字符串，但不会真正执行目标命令，因此很适合放在授权变更和上线前检查里。

官方地址：https://redis.io/docs/latest/commands/acl-dryrun/

我第一次用这个命令时，最大的误区是只传了命令名，没有把键和其他参数带上。这样最多只能看出命令类别是否被允许，却无法确认 ~app:* 这类键模式是否匹配。真正可靠的做法，是把应用将要发送的完整命令原样放进 DRYRUN。

先明确 ACL DRYRUN 到底测试什么

ACL DRYRUN 从 Redis Open Source 7.0 开始提供，官方语法如下：

# 由有权限的管理连接执行，后面必须带完整目标命令及参数
ACL DRYRUN username command [arg [arg ...]]

这里有三个边界需要先分清：

• 它检查 ACL，不检查登录。目标用户即使处于关闭状态，也可以被拿来做模拟判断。
• 它不执行目标命令。拿 SET 测试时不会真的写入键，拿删除命令测试时也不会删数据。
• 它按完整参数判断。命令权限、键模式以及命令涉及的其他 ACL 资源都可能影响结果。

需要注意，ACL DRYRUN 自己属于管理类命令。也就是说，测试目标用户不必登录，但发起测试的当前连接必须有权调用它。不要把这个能力下放给普通业务账号。

准备一个未开放登录的候选用户

为了演示“授权前测试”，可以先准备一个保持关闭状态的候选用户。下面的规则只允许读取 app: 前缀的键，不允许写入：

# 重置旧规则并保持用户关闭，避免候选账号被实际用于登录
ACL SETUSER release_candidate reset off nopass ~app:* +GET

# 查看当前规则，确认命令权限和键模式是否符合预期
ACL GETUSER release_candidate

在真实环境里，不一定要临时新建用户；你也可以对已经存在但尚未开放给应用的用户执行同样检查。关键是先把“候选 ACL 规则”和“账号正式启用”拆开，避免为了测试而提前暴露凭据。

把完整命令和参数交给 DRYRUN

先测一条应该被允许的读取命令：

# GET 已授权，键名也匹配 app:*，预期返回 OK
ACL DRYRUN release_candidate GET app:profile:42

OK

再测一条键名匹配、但命令未授权的写入：

# 键模式匹配，但用户没有 SET 权限，预期返回拒绝原因
ACL DRYRUN release_candidate SET app:profile:42 enabled

User release_candidate has no permissions to run the 'set' command

最后保留 GET，把键换到规则外：

# GET 已授权，但 private:* 不匹配 ~app:*，预期得到键访问拒绝原因
ACL DRYRUN release_candidate GET private:profile:42

这三组结果能快速把问题分层：第一组证明目标组合可用；第二组说明应检查命令规则；第三组说明应检查键模式。比起先启用账号、再用业务连接反复试错，这种方式更容易控制测试范围。

根据拒绝原因做最小授权

排障时不要看到拒绝就直接给 +@all 和 ~*。如果应用确实需要写入 app:profile:，可以只补它需要的命令，同时保持键空间边界：

# 只增加 SET，保留现有 app:* 键范围，不扩大到所有命令和所有键
ACL SETUSER release_candidate +SET

# 正向验证：预期允许对 app:* 执行 SET，但目标写入不会真的发生
ACL DRYRUN release_candidate SET app:profile:42 enabled

# 反向验证：预期仍拒绝 app:* 之外的键，防止规则放得过宽
ACL DRYRUN release_candidate SET private:profile:42 enabled

我通常会把正向样例和反向样例一起保存到发布清单里。正向样例证明业务路径已经打通，反向样例则证明授权边界还在。如果只看 OK，很容易在追加规则时无意间把键空间扩大。

返回值处理最容易踩的坑

官方文档说明：允许时是简单字符串 OK，拒绝时是描述原因的字符串。拒绝结果不一定以客户端异常的形式出现，因此自动化脚本不能只依赖“命令有没有抛错”，还要显式判断返回内容是否等于 OK。

# redis-cli --raw 便于脚本读取纯文本；非 OK 内容应被视为权限检查失败
result=$(redis-cli --raw ACL DRYRUN release_candidate GET app:profile:42)

# 只接受精确的 OK，其他文本原样记录为拒绝原因
if [ "$result" = "OK" ]; then
  printf '%s\n' 'ACL 检查通过'
else
  printf 'ACL 检查未通过：%s\n' "$result"
  exit 1
fi

另外，DRYRUN 只能回答 ACL 是否允许，并不能替代命令语义、数据类型、脚本逻辑、网络连接或应用凭据测试。一条命令通过 ACL 检查，不代表它在真实数据上一定成功；正式上线前仍要在隔离环境中完成业务级验证。

上线前检查清单

常见问题

ACL DRYRUN 会真的写入或删除数据吗？

不会。它模拟指定用户执行目标命令时的 ACL 判断，不执行目标命令本身。

目标用户必须先启用吗？

不必。官方说明明确指出，可以在不启用用户的情况下测试其权限，这正是它适合授权前检查的原因。

为什么命令名有权限，DRYRUN 还是拒绝？

最常见的原因是完整参数涉及的键不匹配用户的键模式。把真实键名和参数一起传入，再根据返回原因检查 ~pattern。

DRYRUN 返回 OK 后就能直接上线吗？

不能把它当成完整集成测试。它只证明这条具体命令在当前 ACL 规则下被允许；账号启用、认证配置、网络、数据类型和业务逻辑仍需单独验证。