Redis ACL 的 key pattern 为什么放行了意外键

我排查 Redis ACL 时，最容易误判的一点是：看到用户配置了 ~tenant-a:*，就以为它只能访问这一组键。实际上，Redis 会把同一个用户已有的 key pattern、命令权限和 selector 一起计算；旧规则没有清掉、通配符范围过宽，或者命令本身不带具体 key，都可能让“意外键”看起来被放行。

先执行 ACL GETUSER 用户名 看生效规则，再用 ACL DRYRUN 用户名 命令 参数 做无副作用验证。最稳妥的修复方式是以 reset 重建权限，明确区分根规则和 selector，而不是继续追加一个更窄的 pattern。

先把真正生效的规则展开

不要只看部署文件里最近改的那一行。Redis 官方文档说明，ACL SETUSER 会从左到右处理规则；用户已存在时，新调用通常是在原规则上应用变更。先查根规则、键规则和 selector：

# 读取用户当前的完整 ACL，包括根权限和 Redis 7.0+ selector
ACL GETUSER app_reader

# 以 ACL 文件格式查看所有用户的有效规则，便于发现 ~* 或 allkeys
ACL LIST

# 在不真正执行命令的前提下，模拟 app_reader 访问另一租户的键
ACL DRYRUN app_reader GET tenant-b:profile:42

如果回显的 keys 同时有 ~tenant-a:* 和 ~*，答案已经很明确：后者覆盖了前者。若 selectors 里还有一组包含 ~* 或更宽 pattern 的规则，也要一并处理。ACL GETUSER 展示的是用户的有效规则，适合用来对照配置文件和变更记录。

这是Redis ACL key pattern使用通配符匹配时的常见坑：默认规则下`*`、`?`这类通配符的匹配范围比多数开发者预期更广，没有转义特殊字符、或者pattern前缀后缀遗漏边界限制，就会把原本不在权限规划内的键也放行了。排查时优先核对pattern的字符转义规则、键名的实际字符组成，就能快速定位问题根源。

为什么窄 pattern 仍会放行意外键

我通常按下面四个边界逐一排除，避免把“键名匹配”误当成“所有访问都取交集”。

Redis 7.0 起还可以写 %R~pattern 和 %W~pattern，分别限制读、写方向。跨键命令要特别小心：例如把 tenant-b: 的数据复制到 tenant-a:，同一组权限需要分别覆盖源键的读取和目标键的写入；只给其中一个 pattern，不能得到你想要的跨键能力。

用重建而不是叠加修正权限

如果用户是专用业务账号，我更愿意明确重置后再写规则。下面是一个只允许读取和写入 tenant-a: 的示例；密码仅作占位，生产环境不要把真实密码写进脚本或日志。

# reset 先清掉旧的命令、key 和密码规则，避免历史 ~* 残留
ACL SETUSER app_writer reset on >replace-with-secret +GET +SET +DEL ~tenant-a:*

# Redis 7.0+ 可把读写边界拆开；按需选择，不要与 ~* 混用
ACL SETUSER app_reader reset on >replace-with-secret +@read %R~tenant-a:*

# 把高风险的数据库级命令显式移除，它们不靠 key pattern 约束
ACL SETUSER app_writer -FLUSHDB -FLUSHALL -SWAPDB

“最小权限”不等于只写一个 pattern。还要确认命令集合、事务或脚本使用的命令，以及应用是否需要跨键操作。若账号要执行 HGET、HSET，不要只开放一个与数据结构不匹配的命令类别；按真实调用清单逐项增加。

用 DRYRUN 验证允许、拒绝和高风险路径

ACL DRYRUN 从 Redis 7.0 提供无副作用的模拟执行，特别适合把“我以为会拒绝”变成可复查的结果。建议至少覆盖三类键和一类无 key 命令：

# 允许的键：预期返回 OK（以下是示例回显，不代表本文在你的实例执行）
ACL DRYRUN app_writer SET tenant-a:profile:42 active
# OK

# 另一租户：预期返回没有 key 权限
ACL DRYRUN app_writer GET tenant-b:profile:42
# User app_writer has no permissions to access the key

# 无 key 参数的高风险命令：检查它是否仍在命令集合中
ACL DRYRUN app_writer FLUSHALL
# User app_writer has no permissions to run the 'flushall' command

如果意外键仍然返回 OK，回到 ACL GETUSER 搜索所有根 pattern 和 selector，再检查应用实际认证的用户名：连接复用、默认用户和 AUTH/HELLO 切换都可能让你查的是 app_reader，用的却是另一个用户。

上线前留一张小清单

• 用 ACL GETUSER 确认没有遗留 ~*、allkeys 或意外 selector。
• 用真实命令逐个跑 ACL DRYRUN，至少包含读、写、删除、跨键和无 key 参数命令。
• 把 ACL SETUSER 变更写成可重复的声明式脚本，修改前优先 reset，并保留回滚版本。
• 确认业务连接认证的用户名与检查时一致，再让灰度流量验证拒绝路径。

常见问题

只写了 ~tenant-a:*，为什么还能访问别的键？

最常见是旧规则仍包含 ~*，或 selector 中存在更宽的 pattern。先看 ACL GETUSER 的 keys 和 selectors。

~pattern 能限制 FLUSHALL 吗？

不能。FLUSHALL 没有具体 key 参数，需从命令权限中移除；同理检查 FLUSHDB、SWAPDB 等数据库级命令。

Redis 6 能使用 ACL DRYRUN 吗？

不能把它作为 Redis 6 的通用检查手段；官方命令文档标注 ACL DRYRUN 从 Redis 7.0 起提供。旧版本应在隔离环境用测试账号和真实命令验证。