Redis ACL 怎样限制用户可订阅的频道前缀

Redis ACL 限制用户可订阅的频道前缀，需要使用 &前缀*，例如 &tenant42:*。同时还要授予 SUBSCRIBE 或 PSUBSCRIBE 命令权限：频道范围与命令权限缺一不可。~tenant42:* 限制的是键，不是 Pub/Sub 频道。

下面针对普通 Pub/Sub，适用于支持频道 ACL 的 Redis 6.2 及以上版本。示例只配置一个已有独立密码、没有额外选择器授权的专用测试用户，不修改 default 用户，不讨论分片订阅或整个实例的安全配置。

官方 ACL 文档：https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/

先给订阅用户一份最小规则

假设该用户只接收 tenant42 的事件，不发布消息，也不读写 Redis 键。由管理员在测试实例执行：

# 仅由有 ACL 管理权限的管理员执行；目标必须是已配置独立密码的专用测试用户
# 清空原频道范围与键范围，再只开放订阅相关命令；不修改已有密码
redis-cli ACL SETUSER demo_channel_reader on resetkeys resetchannels '-@all' '+subscribe' '+unsubscribe' '+psubscribe' '+punsubscribe' '+ping' '&tenant42:*'

这条配方从“没有旧频道范围、没有普通命令授权”开始，再添加所需命令与频道规则。on 启用用户，但不设置密码；密码必须提前由管理流程配置。若用户名不存在，ACL SETUSER 会创建用户，而这条命令本身并不是完整的账号凭据初始化流程，因此不能直接当作从零创建可登录用户的脚本。

配置中没有 +publish，所以即使频道名匹配，也没有发布权限。+ping 用于连接探测；其余四个命令分别支持精确订阅、模式订阅及对应取消订阅。若客户端还自动发出其他命令，应按客户端需要单独分析，不要直接补上所有命令权限。

频道前缀用 &，不是 ~

ACL 的 ~模式 与 &模式 是两个对象范围。前者对应键，后者对应 Pub/Sub 频道；冒号只是频道名称的普通字符，不会自动形成租户隔离规则，隔离来自你设置的模式与调用身份。

对 SUBSCRIBE，频道名 tenant42:status 匹配允许的 glob 模式；tenant77:status 不匹配。用户必须以自己的账号完成认证，不能用有广泛权限的管理员连接来证明应用账号受限。

PSUBSCRIBE 的模式需要原样匹配

PSUBSCRIBE 比 SUBSCRIBE 更容易误解。频道 ACL 对精确频道名做 glob 匹配，但对于 PSUBSCRIBE，请求的模式必须与某个获准频道模式字面一致。只配置 &tenant42:* 时，PSUBSCRIBE tenant42:* 符合这项条件；PSUBSCRIBE tenant42:news:* 不能仅凭范围看似更窄就自动通过。

这不是 ACL 在推导两个模式的数学包含关系。客户端如果会生成更细的模式，就应把需要的模式逐条纳入授权设计，或者使用精确频道订阅。正文中的比较只讨论上面这一份专用用户规则，不包括另外的选择器授权。

# 管理员为专用测试用户额外允许这一条原样的模式；不是覆盖已有规则
redis-cli ACL SETUSER demo_channel_reader '&tenant42:news:*'

# 对应的模式订阅才有明确授权，观察后由读者按 Ctrl+C 结束
redis-cli --user demo_channel_reader --askpass PSUBSCRIBE 'tenant42:news:*'

新增的模式与原有模式并存。它使对应模式订阅获得明确许可，不意味着其他任意 tenant42 子模式都被自动授权。

旧的宽权限要先清掉

ACL SETUSER 对已有用户应用增量规则。假如之前存在 &* 或 allchannels，只增加一条窄模式并不会收回原来的全频道范围。最小配方先 resetchannels，再添加允许的模式，正是为了避免这种残留。

类似地，只追加订阅命令不会撤销原先的 PUBLISH 或其他命令。配方中的 -@all 先移除普通命令授权，然后按从左到右的顺序补回明确需要的命令。相关命令行为见官方参考：https://redis.io/docs/latest/commands/acl-setuser/。

Redis 7.0 及以上还可能通过选择器提供另一套授权。根规则收紧后，额外选择器仍可能满足请求。因此示例要求该专用用户没有额外选择器；不能把这条配方直接套在复杂现有业务用户上，声称它撤销了所有其他授权来源。需要处理选择器时应另做明确的账号权限变更，不盲目删除现有业务规则。

在专用测试连接看允许与拒绝

以下是供读者在测试实例执行的操作示例，本文未运行 Redis 命令或收集真实输出。测试用户已有密码，管理员连接和用户连接指向同一测试实例。先只应用最小配方，不要先执行上面的新增模式变体。

# 逐条单独运行：--askpass 让读者输入已有密码，不把密码写进命令
# 精确频道位于允许前缀，预期可订阅；订阅连接会持续等消息，观察后按 Ctrl+C 结束
redis-cli --user demo_channel_reader --askpass SUBSCRIBE tenant42:status

# 其他前缀不在频道规则内，预期出现权限拒绝
redis-cli --user demo_channel_reader --askpass SUBSCRIBE tenant77:status

# 模式与 ACL 中的 tenant42:* 字面一致，预期可订阅
redis-cli --user demo_channel_reader --askpass PSUBSCRIBE 'tenant42:*'

# 看似更小的模式未被单独授权，预期拒绝，而不是自动推导包含关系
redis-cli --user demo_channel_reader --askpass PSUBSCRIBE 'tenant42:news:*'

预期结果是：tenant42:status 允许、tenant77:status 拒绝；PSUBSCRIBE tenant42:* 允许，而 tenant42:news:* 在尚未单独添加时拒绝。这些结果来自文档规则，不是本机实测记录。完成这一轮后再执行变体，才是在比较新增规则的含义。

订阅成功只说明该用户获准进入对应订阅状态。没有发布者发送消息时，连接仍可能没有消息可显示，不能把“暂时没收到消息”解释为 ACL 拒绝。鉴权错误与 NOPERM 权限错误也不是同一件事，应先确认使用的是正确账号，再区分命令与频道范围。

部署前处理连接与持久化范围

resetchannels 收紧后，已无法访问其订阅频道或模式的 Pub/Sub 客户端可能被断开。生产变更需要安排应用重连，并确保重连继续使用受限用户；不能为了恢复连接改回管理员账号。

运行时 ACL 变更与配置落盘也应分开管理。使用外部 ACL 文件的部署，需要把相应用户规则纳入该配置来源；不能假设执行一次 ACL SETUSER 就完成持久化。配置是否来自文件或托管服务，应遵循现有管理流程，本文不代替完整部署操作。

常见问题

频道模式会让用户有发布权限吗？不会自动授予命令。示例未开放 PUBLISH，所以匹配的频道也不能凭这条规则发布。

为什么精确订阅能用，模式订阅却被拒绝？除命令授权外，PSUBSCRIBE 要求模式原样匹配，不能直接套用精确频道名的比较方式。

可以只加一条前缀规则收紧旧账号吗？不能保证。原有全频道范围、命令授权以及选择器需要分别考虑。

频道前缀限制要同时确定账号身份、命令范围和频道模式。对于只订阅的专用用户，清晰地撤掉旧宽范围，再列出确实需要的订阅形式，比依赖隐含默认值更容易维护。