Redis Sentinel 认证配置的一致性清单

Redis Sentinel 认证配置的一致性，不是让全部组件使用同一个密码，而是让每一条连接的发送方凭据与接收方认证规则相匹配。数据节点、复制连接、Sentinel 监控连接和客户端发现连接要分别登记；当前从节点还必须具备升主后的接入条件。

官方地址：https://redis.io/

下面针对自建、非 Cluster 主从部署给出密码模式参考。所有占位符必须替换成独立生成的强随机秘密；片段不是完整生产配置，也不包含网络、TLS、持久化和部署编排。

把一致性限定到同一认证关系

密码模式下，可以用一组数据密码与一组 Sentinel 密码表达上述关系，两组不必相同。这种方式便于解释配置对应关系，但不能提供业务用户与管理用户之间的细粒度隔离。新建有权限隔离要求的部署应考虑 ACL，不把此处密码模式当作完整加固基线。

为所有可能切换角色的数据节点准备凭据

不要只在当前主节点设置入口密码。主从可能换位，所有候选数据节点都要具备一致的数据入口认证，以及成为从节点时需要的复制认证。以下片段放在各数据节点的 redis.conf 中；具体地址和 replicaof 拓扑由部署另行配置。

# 数据节点入口：所有候选主从使用同一组数据密码
requirepass "REPLACE_WITH_RANDOM_DATA_SECRET"
# 角色变为从节点时，访问目标主节点所用的密码
masterauth "REPLACE_WITH_RANDOM_DATA_SECRET"

这里的占位符没有环境变量替换含义，Redis 不会自动从密钥系统取值。配置管理工具需要在受控环境中渲染真实值，限制文件读取权限，并避免把成品配置提交到代码仓库。

采用 ACL 时，应分别考虑应用用户、复制用户和 Sentinel 管理用户。复制连接用 masteruser 与 masterauth 指定身份，目标节点允许复制所需命令；每个可能升主的节点都要准备相应规则。不要以为业务数据复制成功就能代替各节点的 ACL 配置管理。相关命令范围见 官方 ACL 说明。

区分 Sentinel 访问 Redis 与访问同伴的密码

假设受监控组名为 cache-main、当前主地址为示例内网地址 10.20.0.11，三个 Sentinel 各自使用可达的监听地址。每个 Sentinel 都需要以下认证相关片段：

# 监控对象名必须与下面的认证对象名一致；地址需按实际部署替换
sentinel monitor cache-main 10.20.0.11 6379 2
# Sentinel 访问这个组的 Redis 主节点和从节点
sentinel auth-pass cache-main "REPLACE_WITH_RANDOM_DATA_SECRET"
# Sentinel 自身入口认证；密码模式下同组 Sentinel 使用同一值
requirepass "REPLACE_WITH_RANDOM_SENTINEL_SECRET"

auth-pass 后的名字是受监控组名，不是用户名。它负责 Sentinel 到数据节点的连接，不能用来保护 26379 入口。密码模式下 Sentinel 的 requirepass 同时涉及入站连接和同伴认证，不能只改其中一台。

ACL 部署则用 sentinel auth-user 与 auth-pass 指定数据节点身份；Sentinel 同伴的出站身份另由 sentinel sentinel-user、sentinel sentinel-pass 配置。不能把这两对选项当成同一件事，也不要将 requirepass 示例与外部 aclfile 混拼。应以部署版本附带配置为准，官方 Sentinel 配置注释可用于理解这些选项的用途，但 unstable 分支不是部署版本保证。

在客户端分别填写发现和数据连接认证

客户端配置至少要明确 Sentinel 地址列表、组名 cache-main、Sentinel 认证，以及 Redis 数据认证。不同语言和驱动的字段名不同，不能看到一个 password 字段便认定它同时覆盖两种连接。

发现成功仅说明客户端能问到地址，不代表它能登录该地址；能访问旧主节点也不说明访问候选新主节点时仍能认证。下面是读者在隔离环境中进行只读核对的命令示例，没有在本文环境执行：

# 交互提示输入 Sentinel 密码，不在命令行参数中写明文密码
redis-cli -h 10.20.0.21 -p 26379 --askpass SENTINEL get-master-addr-by-name cache-main
# 将地址替换为上条实际返回的数据节点，交互输入数据密码
redis-cli -h 10.20.0.11 -p 6379 --askpass PING

前一条应返回当前主节点地址，后一条成功时应得到 PONG；这些是判断条件，不是本文测得的输出。启用 TLS 的环境还需使用正确的 TLS 参数和证书，不能照抄明文 TCP 示例来替换原有传输保护。

按认证错误保留脱敏记录

记录出错连接属于哪一层、目标地址、身份名称、配置修订号和错误类型即可，不记录秘密。NOAUTH 通常指连接尚未完成认证；WRONGPASS 需要核对用户、密码及启用状态；NOPERM 应转向命令、键或频道授权，而不是不断换密码。

建议把“能连通”“认证成功”“发现成功”“复制正常”“应用可用”分列记录，避免用一次 PING 代替全部结果。Sentinel 有监控和重配置职责，给它仅供业务 GET/SET 使用的用户往往不够；也不应因此把高权限管理身份发给应用。

用发布清单覆盖切换和重启

• 每个候选数据节点：入口认证、复制凭据和权限规则均有配置来源。
• 每个 Sentinel：组名相同，数据监控凭据正确，同伴认证模式一致。
• 每个应用：发现连接与数据连接分别配置，能够处理主地址变化。
• 每份配置：确认运行时设置与持久化来源相符，重启不会回到旧凭据。
• 受控演练：在测试环境覆盖候选节点升主、旧主回归及客户端重新发现；此处不提供直接触发生产切换的命令。

只改 auth-pass 能修复客户端登录 Sentinel 失败吗？不能，它处理的是 Sentinel 访问 Redis 的认证关系。

所有密码一样是否更可靠？不是。需要一致的是同一连接双方的约定，而不是让应用、复制和管理角色共享全部权限。

改完文件就等于线上生效吗？不等于。变更应遵循既有受控发布方式，分别记录运行态与重启后的结果，切勿凭文件内容推断全链路成功。

完整高可用语义及认证章节参见 Redis Sentinel 官方文档。认证清单只解决身份匹配问题，不承诺故障时零数据丢失，也不能替代网络隔离、传输加密和定期演练。