From a662f44ca2eee7486b9b9006925fe66e27449780 Mon Sep 17 00:00:00 2001 From: Moti Cohen Date: Thu, 9 Jul 2026 11:34:40 +0300 Subject: [PATCH 1/3] Document Pub/Sub ACL risk on Sentinel-monitored nodes Warn against granting broad Pub/Sub channel access (allchannels / &*) on Sentinel-monitored Redis nodes. Any client able to publish to the reserved __sentinel__:hello channel can inject forged, unauthenticated topology messages and trigger spurious failovers or a denial of service. Co-Authored-By: Claude Opus 4.8 (1M context) --- .../oss_and_stack/management/sentinel.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/content/operate/oss_and_stack/management/sentinel.md b/content/operate/oss_and_stack/management/sentinel.md index 4be6502df0..274913f762 100644 --- a/content/operate/oss_and_stack/management/sentinel.md +++ b/content/operate/oss_and_stack/management/sentinel.md @@ -819,6 +819,24 @@ Where `` and `` are the username and password for accessing 127.0.0.1:6379> ACL SETUSER sentinel-user ON >somepassword allchannels +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill +{{< warning >}} +Sentinel discovery relies on the reserved `__sentinel__:hello` Pub/Sub channel on each +monitored master and replica. Sentinels periodically publish their presence there and +subscribe to it to discover other Sentinels and learn the current topology. The messages +carry no authentication and are trusted by receiving Sentinels, so any client that can +publish to this channel on a monitored node can inject forged topology information and +trigger spurious failovers or a denial of service. + +Because of this, do not grant broad Pub/Sub access on Sentinel-monitored Redis nodes: + +* Avoid `allchannels` (equivalently `&*`) for any user other than the Sentinel `auth-user` + itself. Since Redis 7.0 the default `acl-pubsub-default` is `resetchannels`, so new ACL + users have no channel access unless you explicitly grant it. Be especially careful with + the legacy `default` user, which may retain broad access. +* Treat the `__sentinel__:` channel prefix as reserved. Grant access to it only to the + Sentinel `auth-user`, and only where Sentinel functionality requires it. +{{< /warning >}} + ### Redis password-only authentication Until Redis 6, authentication is achieved using the following configuration directives: From caef1455aefdaab0250835d0a21c2c5d8e0207e3 Mon Sep 17 00:00:00 2001 From: Moti Cohen Date: Thu, 9 Jul 2026 12:01:25 +0300 Subject: [PATCH 2/3] Narrow Sentinel ACL example to only the __sentinel__:hello channel Correct the guidance: the Sentinel auth-user does not need allchannels. Sentinel only ever SUBSCRIBEs to and PUBLISHes on the exact __sentinel__:hello channel on monitored nodes, so resetchannels &__sentinel__:hello is sufficient. Validated against the Redis sentinel TCL test suite (fresh sentinel + replica auto-discovery and a manual failover all succeed with the auth-user restricted to that one channel; a negative control confirms discovery breaks when the channel is denied). Co-Authored-By: Claude Opus 4.8 (1M context) --- .../oss_and_stack/management/sentinel.md | 21 ++++++++++++------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/content/operate/oss_and_stack/management/sentinel.md b/content/operate/oss_and_stack/management/sentinel.md index 274913f762..96b91d5f05 100644 --- a/content/operate/oss_and_stack/management/sentinel.md +++ b/content/operate/oss_and_stack/management/sentinel.md @@ -817,24 +817,29 @@ following directives: Where `` and `` are the username and password for accessing the group's instances. These credentials should be provisioned on all of the group's Redis instances with the minimal control permissions. For example: - 127.0.0.1:6379> ACL SETUSER sentinel-user ON >somepassword allchannels +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill + 127.0.0.1:6379> ACL SETUSER sentinel-user ON >somepassword resetchannels &__sentinel__:hello +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill + +The only Pub/Sub channel that Sentinel uses on a monitored node is `__sentinel__:hello`, so +this user is granted access to that channel only (`resetchannels &__sentinel__:hello`) rather +than to all channels (`allchannels`, equivalently `&*`). {{< warning >}} Sentinel discovery relies on the reserved `__sentinel__:hello` Pub/Sub channel on each monitored master and replica. Sentinels periodically publish their presence there and -subscribe to it to discover other Sentinels and learn the current topology. The messages +subscribe to it to discover other Sentinels and learn the current topology. These messages carry no authentication and are trusted by receiving Sentinels, so any client that can publish to this channel on a monitored node can inject forged topology information and trigger spurious failovers or a denial of service. Because of this, do not grant broad Pub/Sub access on Sentinel-monitored Redis nodes: -* Avoid `allchannels` (equivalently `&*`) for any user other than the Sentinel `auth-user` - itself. Since Redis 7.0 the default `acl-pubsub-default` is `resetchannels`, so new ACL - users have no channel access unless you explicitly grant it. Be especially careful with - the legacy `default` user, which may retain broad access. -* Treat the `__sentinel__:` channel prefix as reserved. Grant access to it only to the - Sentinel `auth-user`, and only where Sentinel functionality requires it. +* No user needs access to all channels (`allchannels` / `&*`). The Sentinel `auth-user` + needs access only to the `__sentinel__:hello` channel (`&__sentinel__:hello`), and no + other user should be able to publish to or subscribe to it. Since Redis 7.0 the default + value of `acl-pubsub-default` is `resetchannels`, so newly created ACL users have no + channel access unless you grant it explicitly. Be especially careful with the legacy + `default` user, which may still have broad access. +* Treat the `__sentinel__:` channel prefix as reserved for Sentinel's internal use. {{< /warning >}} ### Redis password-only authentication From 42d065dd3128c09d0038d1729fdf2ef671eb3076 Mon Sep 17 00:00:00 2001 From: David Dougherty Date: Thu, 9 Jul 2026 07:51:10 -0700 Subject: [PATCH 3/3] Apply suggestion from @dwdougherty --- content/operate/oss_and_stack/management/sentinel.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/operate/oss_and_stack/management/sentinel.md b/content/operate/oss_and_stack/management/sentinel.md index 96b91d5f05..cf58e6d705 100644 --- a/content/operate/oss_and_stack/management/sentinel.md +++ b/content/operate/oss_and_stack/management/sentinel.md @@ -835,7 +835,7 @@ Because of this, do not grant broad Pub/Sub access on Sentinel-monitored Redis n * No user needs access to all channels (`allchannels` / `&*`). The Sentinel `auth-user` needs access only to the `__sentinel__:hello` channel (`&__sentinel__:hello`), and no - other user should be able to publish to or subscribe to it. Since Redis 7.0 the default + other user should be able to publish to or subscribe to it. Since Redis 7.0, the default value of `acl-pubsub-default` is `resetchannels`, so newly created ACL users have no channel access unless you grant it explicitly. Be especially careful with the legacy `default` user, which may still have broad access.