Redis 7.4怎么配置多租户ACL Redis安全访问权限精细化详解

Redis 7.4 多租户 ACL 配置：从“形同虚设”到“真隔离”的关键几步

Redis 7.4 确实引入了多租户 ACL 能力，但这里有个关键前提：你必须彻底关闭 default 用户，并为每个租户显式定义独立的用户，最后通过 aclfile 加载配置。如果跳过这些步骤，所有连接依然会走默认的超级权限，所谓的多租户隔离也就形同虚设了。

如何实现租户间的 Key 访问隔离？关键在于 ~pattern 而非 ~*

在 Redis 7.4 的多租户 ACL 体系中，Key 的访问权限是通过以 ~ 开头的模式来控制的，数据库编号（DB）不再是隔离单元。举个例子，如果想让租户 tenant_a 只能操作其专属前缀下的 Key，配置应该这样写：

user tenant_a on >pass123 ~tenant_a:* +@read +@write -@admin -@dangerous

听起来简单，但实践中容易踩几个坑：

• 模式不完整：写成 ~tenant_a 是无法匹配任何 Key 的，因为缺少了通配符 *。
• 前缀匹配的精确性：模式 ~tenant_a:* 可以匹配 tenant_a:session:abc，这没问题。但如果应用使用了 tenant_a_session:abc（用下划线替代了冒号），那么这次访问就属于越权了。记住，ACL 模式是严格的前缀匹配，并非模糊搜索。
• 模式共享的风险：如果多个租户共用类似 ~tenant_* 的模式，会导致他们能互相读写数据，隔离性完全丧失。

aclfile 配置文件：那些不容妥协的硬性规则

aclfile 是 Redis 7.4 持久化加载 ACL 配置的唯一方式（通过 ACL SETUSER 命令修改的配置仅存在于内存，重启即丢失）。不过，这个文件格式有几条必须严格遵守的规则：

• 行首必须是 user：每一行有效配置都必须以 user 关键字开头。即使是注释行，如果写成 # admin user 也会被 Redis 解析器视为非法语法，导致服务启动失败并报错 Invalid ACL line。
• 密码格式必须紧凑：密码必须紧跟在 > 符号之后，中间不能有任何空格。正确格式是 >mypass，而 > mypass 会导致解析失败。
• 不支持跨行定义：每个用户的完整 ACL 规则必须在单行内写完。对于较长的命令列表，建议先在外部脚本中拼接好，再一次性写入文件。
• 路径需显式指定：必须在 redis.conf 中通过 aclfile /etc/redis/users.acl 这样的指令明确指定文件路径，并且确保 Redis 进程对该路径拥有读取权限。

哨兵与集群环境：从节点如何完成租户身份验证？

在 Redis 7.4 的哨兵或集群部署中，从节点本身并不维护独立的 ACL 用户表，它依赖于从主节点同步认证信息。因此，必须在从节点的配置文件中显式设置以下两项：

masteruser tenant_b
masterauth pass456

如果缺少这两项配置，从节点将无法连接主节点，通常会报出 NOAUTH Authentication required 或 ERR invalid password 错误。这里有几点需要特别注意：

• masteruser 指定的必须是主节点 aclfile 中已明确定义的用户名，不能是已经被关闭的 default 用户。
• masterauth 需要填写对应用户的明文密码，而非密码哈希值。即使主节点存储的是哈希密码，从节点配置也只认明文字段。
• 集群节点间用于通信的 Gossip 协议不走 ACL 认证，但客户端直接连接到任何一个节点时，仍然需要单独使用该节点上定义的用户进行认证。

一个设计矛盾：ACL GETUSER 显示哈希，为何 aclfile 却要明文？

这是 Redis 7.4 ACL 机制中一个值得注意的设计点：运行时通过 ACL GETUSER 命令查看到的密码，是服务端内部存储的 SHA256 哈希值（形如 #515c217e...）；然而，aclfile 配置文件解析器只识别 >password 格式的明文密码。这两者并不互通。

这个矛盾直接导致了几个操作上的影响：

• 禁止直接复制粘贴：你不能将 ACL GETUSERaclfile 中，这必然会导致 Redis 启动失败。
• 密码轮换需双写操作：更新密码时，需要两步走：先在运行时执行 ACL SETUSER u1 >newpass，然后必须手动更新 aclfile 文件中的明文密码，最后执行 ACL LOAD 使其生效。
• 建议自动化管理：在生产环境中，强烈建议使用配置中心或自动化工具来管理 aclfile 的内容，避免因人工操作失误导致服务中断。

最后，还有一个极易被忽略的细节：ACL 规则的顺序直接影响最终权限。规则从左到右逐条生效，且不可逆。例如，规则 +@all -@dangerous +flushdb 最终会允许执行 flushdb 命令（因为它在最后被显式添加了）。但如果写成 +@all +flushdb -@dangerous，那么 flushdb 的权限又会被紧随其后的 -@dangerous 类别规则覆盖掉，导致命令无法执行。理解这个顺序逻辑，对于精确控制权限至关重要。