Redis ACL DRYRUN 怎么验收：命令权限、密钥权限与最小授权

给订单服务新建Redis账号的时候，最容易出问题的从来不是密码设置，而是权限边界没划清楚：账号能跨业务读到其他模块的键，或者明明约定只允许 GET，却连业务自身的写入请求都跑不通。Redis 的 ACL DRYRUN 可以在不真正执行命令的前提下做模拟权限判断，刚好可以把「什么操作应该放通、什么请求必须拦截」做成发布前的固定回归检查项。

先定义一个只读订单账号

假设订单服务只需要读取 orders: 前缀下的键，不该碰库存、用户资料这类其他业务的键，也不能用管理类命令。我们可以从一个完全干净的新用户开始配置：

ACL SETUSER order_reader reset on \
  -@all +get +mget +exists \
  ~orders:*

reset 会直接清空该用户名下所有已有规则，避免之前遗留的权限继承问题；on 用来设置认证密码；-@all 先把所有权限全部收紧，再逐项添加业务真正需要用到的命令。命令规则和键匹配规则是两条完全独立的校验边界，少写任意一条，最终生效的权限结果都会和预期不一样。

用 ACL DRYRUN 先测命令，再测键

ACL DRYRUN username command [arg ...] 全程只做权限逻辑模拟，不会真的读取或者修改业务数据。我们可以先验证正常读取场景，以及明确禁止的写入场景：

ACL DRYRUN order_reader GET orders:1001
ACL DRYRUN order_reader SET orders:1001 pending
ACL DRYRUN order_reader GET inventory:sku-9

第一条应该返回 OK；第二条应该因为没有 SET 权限被拦截；第三条即便有 GET，也会因为键模式不匹配直接拒绝。测试的时候别只记录成功的用例，拦截的原因才是权限回归最有价值的校验依据。

把权限矩阵写成可重复的检查脚本

上线前至少要覆盖四类组合：允许的读命令、未授权的写命令、合法命令访问错误键前缀、以及管理类命令越权访问。可以先在临时Redis实例或者隔离测试账号上跑完全部用例：

tests=(
  'GET orders:1001'
  'MGET orders:1001 orders:1002'
  'SET orders:1001 paid'
  'GET inventory:sku-9'
  'CONFIG GET maxmemory'
)

for test_case in "${tests[@]}"; do
  read -r command arg  ' "$test_case"
  redis-cli ACL DRYRUN order_reader "$command" "$arg"
done

示例里的校验逻辑最好直接整合到CI或者发布自动化脚本里，不要只靠人工看终端输出判断结果。给每条测试用例标注好「预期放通/预期拦截」，同时把当前用户的规则版本写到测试记录里；后续调整权限规则之后，出问题的用例可以直接定位到是命令规则还是键模式改坏了。

用 ACL GETUSER 核对实际生效规则

ACL SETUSER 是增量修改逻辑：对已经存在的用户追加规则的时候，之前的旧规则不会自动消失。所以提交权限变更之前，一定要先读取当前账号的实际生效配置：

ACL GETUSER order_reader

重点核对 flags、commands 和 keys 这三项。如果发现实际生效的规则比变更单里写的多，先用 reset 重建一套最小权限规则，不要靠追加几个减号权限的方式补漏洞。生产环境的演示不要用真实业务密码，密码轮换和ACL文件持久化要放在受控的运维流程里操作。

命令类别很方便，但不要把它当成精确授权

+@read、+@write 可以快速给一组同类命令授权，但随着Redis版本升级或者第三方模块加载，这个命令组的范围可能悄悄变大。对订单读取这类边界非常明确的服务，直接显式列出 GET、MGET、EXISTS 更容易做权限审查；如果确实需要用到类别授权，也要搭配 ACL CAT 确认当前类别下实际包含的所有命令。

ACL CAT read
ACL CAT write
ACL DRYRUN order_reader GET orders:1001
ACL DRYRUN order_reader DEL orders:1001

不要用 +@all 再减去几个已知危险命令的方式来代替最小授权。Redis官方文档明确提示，+@all 后续还会自动包含模块、系统层面加载的新命令；对于只需要少量基础数据操作的业务账号来说，这个默认的权限范围太大了。

发布时保留快照，失败就按快照回退

权限发布和普通服务配置发布一样，必须有可追溯、可回退的快照证据。变更前先保存 ACL GETUSER order_reader 的输出结果，变更完成后重新跑一遍全量权限矩阵校验；如果某条核心读路径被拦截，或者发现了越权访问的情况，立刻停用新规则，按照之前的审计记录恢复上一版的合法规则。

• 发布前：保存旧规则、测试用例和 Redis 实例标识。
• 发布后：重复允许/拒绝两组 DRYRUN，并用真实测试账号做一次连接验证。
• 发现越权：立即阻断发布，撤回新增命令或键模式，检查已有连接是否需要重新认证。
• 完成收口：把新规则版本、检查结果和审批记录绑定在同一个变更单里。

常见问题

ACL DRYRUN 会真的执行 GET 或 SET 吗？

不会。它只会模拟指定用户的权限判断逻辑，不会产生命令本身的业务副作用；真正的数据读写正确性验证，还是要在隔离测试环境或者专用测试账号上操作。

有了 +get，为什么读取 orders:1001 仍然被拒绝？

命令权限和键权限是两条独立的校验规则。除了要允许 GET，还要保证键的匹配规则覆盖这个键，比如 ~orders:*；两个条件都满足，用户才能正常访问该键。

ACL SETUSER 重复执行会覆盖旧权限吗？

默认是增量追加应用，不会自动清空用户名下的旧规则。想要从头定义全新规则的时候，把 reset 放在所有规则的最前面，同时在变更前后用 ACL GETUSER 做配置对比。

业务账号可以直接使用 +@read 吗？

可以作为权限配置的起步参考，但它不是精确的最小权限清单。对权限敏感度高的服务，优先显式列出业务实际需要用到的命令，再用DRYRUN覆盖所有越权访问的测试路径。

Redis ACL 验收的核心从来不是「用户能不能连上Redis」，而是权限矩阵的结果是否稳定：允许的命令只能访问到指定前缀的键，未授权命令和访问其他业务键的请求都被拦截，规则每次变更都有快照可以回退。把 ACL SETUSER、ACL GETUSER 和 ACL DRYRUN 串成固定的发布检查流程，最小授权才不会只是停留在配置文档的口号上。