Redis ACL 怎样只允许消费者读取指定命令

消费者账号明明只需要读取几类数据，却经常因为一条宽泛的 ACL 规则拿到了不该拥有的命令权限。更稳妥的做法是把“能调用哪些命令”和“这些命令能碰哪些 key”分开收紧：命令逐条放行，key 用前缀限制，最后分别测试成功和拒绝结果。

官方资料：https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/

如果目标是“只允许消费者读取指定命令”，不要从 +@all 或宽泛的 +@read 开始。先清空旧规则，再只加入业务真正需要的读取命令，并配上允许访问的 key 模式。

先把消费者的读取动作列成白名单

我排查这类权限时，第一步不会先改 ACL，而是把消费者代码里实际发出的 Redis 命令列出来。假设这个消费者只读 consumer:orders: 前缀下的字符串、哈希和列表数据，那么最小集合可以是 GET、MGET、EXISTS、HGET、HGETALL、LRANGE，以及用于观察生命周期的 TTL、PTTL。

这里故意不使用 +@read。命令分类适合快速了解一组能力，但它会让白名单随 Redis 命令分类变化而扩大；如果业务要求“指定命令”，逐条列出更容易审计。还要单独决定是否允许 PING、SELECT 或事务命令，它们不是数据读取本身，不能因为客户端习惯就顺手放开。

创建用户时同时收紧命令和 key

下面的示例创建一个名为 order_consumer 的用户。reset 先清理已有权限，on 允许用户登录；后面的每个 +command 是精确的命令白名单，~consumer:orders:* 则把 key 范围限制在订单消费者数据前缀内。

# 创建只读消费者：先清掉旧规则，再逐条放行真实需要的读取命令
redis-cli ACL SETUSER order_consumer reset on \
  '>replace-with-a-strong-password' \
  '~consumer:orders:*' \
  '+PING' '+GET' '+MGET' '+EXISTS' \
  '+HGET' '+HGETALL' '+LRANGE' '+TTL' '+PTTL'

# 查看用户当前的完整规则，确认没有遗留的宽泛权限
redis-cli ACL GETUSER order_consumer

密码只是示例占位符，生产环境不要把真实密码写进脚本仓库或文章。需要注意，ACL 是累积规则，单独追加几条 +GET 并不能保证旧的 +@all 已被移除，所以示例把清理动作放在最前面。

用 ACL CAT 辅助检查，但不要让分类替代白名单

当你不确定某个命令是否属于读取类别时，可以让 Redis 自己列出分类内容。这个动作用于查目录，不代表要把整个分类授予消费者。

# 查看 Redis 当前提供的 ACL 命令分类
redis-cli ACL CAT

# 查看 read 分类包含哪些命令，用来核对客户端真实调用
redis-cli ACL CAT read

# 查看某个用户的命令、key 模式和状态
redis-cli ACL GETUSER order_consumer

Redis 官方文档还特别提醒：模块命令不一定包含在普通命令分类中。如果消费者读取的是 RedisJSON、Search 等模块数据，不能因为 +@read 看起来合理就假设模块命令自动可用；应查清实际命令后显式加入，并继续限制它能接触的 key。

先验证允许的命令能读到正确数据

权限排查不能只看 ACL GETUSER 的文字结果，还要用消费者账号建立一次真实连接。下面把允许的读取动作集中测试，成功结果说明命令白名单和 key 前缀至少在正向路径上匹配。

# 用消费者身份读取允许范围内的 key，密码请替换成实际密钥
redis-cli --user order_consumer --pass 'replace-with-a-strong-password' GET consumer:orders:1001

# 验证哈希、列表和 TTL 读取动作仍然属于允许集合
redis-cli --user order_consumer --pass 'replace-with-a-strong-password' HGETALL consumer:orders:1001
redis-cli --user order_consumer --pass 'replace-with-a-strong-password' LRANGE consumer:orders:queue 0 9
redis-cli --user order_consumer --pass 'replace-with-a-strong-password' TTL consumer:orders:1001

如果这里返回的是业务数据或合法的空结果，说明请求没有被 ACL 拦截；空数据本身不等于权限失败。要把“key 不存在”和“权限不足”区分开，后面还必须测试明确不允许的命令。

再验证未列出的命令会被拒绝

消费者不应该拥有写入、删除、配置或权限管理能力。测试时可以挑一个明显不在白名单里的命令，例如 SET 或 DEL。预期结果是 Redis 返回权限错误，而不是客户端静默成功。

# SET 没有加入白名单，预期返回 command not allowed 类似的权限错误
redis-cli --user order_consumer --pass 'replace-with-a-strong-password' SET consumer:orders:test value

# DEL 同样没有加入白名单，预期被拒绝，不能因为 key 前缀匹配就放行
redis-cli --user order_consumer --pass 'replace-with-a-strong-password' DEL consumer:orders:1001

# CONFIG 和 ACL 属于管理能力，预期同样被拒绝
redis-cli --user order_consumer --pass 'replace-with-a-strong-password' CONFIG GET maxmemory

这三次测试能说明一个重要边界：key pattern 只决定命令能访问哪些 key，不能把一个原本没有命令权限的 SET、DEL 或 CONFIG 变成可用命令。

最后测试越界 key，区分两层拒绝原因

如果消费者拿着允许的 GET 去读取 admin:secret，命令本身是白名单内的，但 key 不匹配 consumer:orders:*，预期仍然被拒绝。这一步能防止排查时只验证“允许的命令”，却忘记验证“允许的对象”。

# GET 是允许命令，但 admin:secret 不符合 key 前缀，预期因 key 权限被拒绝
redis-cli --user order_consumer --pass 'replace-with-a-strong-password' GET admin:secret

# 同一个允许命令访问 consumer:orders 前缀，作为对照应能正常返回或返回空值
redis-cli --user order_consumer --pass 'replace-with-a-strong-password' GET consumer:orders:missing

可以把结果记成一张小表：

规则变更时只改动必要的一条

消费者新增读取动作时，先在代码或调用日志中确认具体命令，再追加一条最小规则，例如需要读取集合长度时只增加 +SCARD，不要为了省事切换成 +@read。变更后重复三组测试：允许命令、未授权命令、越界 key。

如果使用 Redis 7 及以上的 key 权限能力，还可以根据业务需要使用读写权限模式；但本文的消费者示例用普通只读 key pattern 已经足够表达范围。对于没有 key 参数、作用于整个数据库的命令，key pattern 不能替代命令级禁止，因此更要避免把 FLUSHALL、FLUSHDB、SWAPDB 等管理或破坏性命令放进消费者权限。

总结：用两张清单判断 ACL 是否收紧

Redis ACL 的最小消费者权限可以归纳为两张清单：第一张是逐条列出的命令白名单，第二张是允许访问的 key pattern。ACL GETUSER 用来检查配置，ACL CAT 用来查命令分类，真实请求则要同时覆盖允许命令、未授权命令和越界 key。只要这三组结果与预期一致，才能说明“指定命令”和“指定 key”两层边界都生效。

相关问题：

• 为什么 +@read 不能直接等同于业务需要的读取白名单？
• Redis ACL 的 key pattern 能限制没有 key 参数的管理命令吗？
• 消费者需要读取 Redis 模块命令时，为什么要显式添加命令？
• 怎样用 ACL LIST 记录用户规则变更？