This makes it not possible to set, require, and accept an auth request against a sentinel instance. It also means you can prevent sentinel from being communicated with by setting requirepass.

Ideal solution: Add support for AUTH to sentinel.c

Second best solution: Remove support for requirepass from sentinel.

A quick look-see at the code makes it appear the first solution is the simplest.

Comment From: mattsta

I think requirepass working at all for a Sentinel config is just a bleed-through artifact of Sentinel and Redis sharing the same config file parsing code.

Does anybody have a use case where they need a password protected Sentinel? That also implies the Sentinels must provide the same password to each other. So, we'd have to add a sentinel-level password, then all Sentinels would be required to pre-auth all Sentinel communication with the password. It just gets messy from there.

Comment From: therealbill

@mattsta Yeah, I agree it is a bleed through. However, because it is there and is honored it either needs to be excluded/ignored or fully implemented. That is implemented shows it is not just due to config parsing - otherwise it wouldn't be honored.

As to use cases I'd say they are the same as having auth in Redis at all. Why would you want to protect your Redis server but not the process which manages it? given that one of the use cases for Sentinel is service discovery, it makes sense to at least minimally protect that service. It is an information sieve as well.

As to having a directive to pass to other sentinels, yeah I hadn't thought about that but Sentinel already does this for sentinel-master/slave so I don't see a fundamental mess there. Perhaps a config directive named sentinelauth to mirror masterauth. The downside would be that a sentinel could only coordinate with sentinels matching the sentinelauth command as opposed to being in multiple groupings.

I'm not sure that is a use case worth preventing sentinel authentication, however. How often should one expect to have a pod spread across multiple sentinel constellations (thus forming yet another one)?

In either case either honoring requirepass should be explicitly removed or the auth command supported (and some form of sentielconf directive added to handle that aspect). The hybrid state is undesirable as it is inconsistent.

Comment From: mattsta

That is implemented shows it is not just due to config parsing - otherwise it wouldn't be honored.

[technical-correction] Because Redis and Redis Sentinel share much of the same code, they share the same command processing code path, which says "if password is set, require auth." Now, in the sentinel case, "password is set" happens, but there's no way to auth, so you get... stuck. See where auth verification happens in the code.

So, the core problem is: the common config parser allows the password to be set, which triggers the common command code path to ponder: "i haz password! you haz auth?" To which it resolutely decides: "No—you no haz auth." :cat: [/technical-correction]

As to use cases I'd say they are the same as having auth in Redis at all.

That's an ongoing discussion as well. What's the use of an unencrypted single shared password everywhere? :-\

Why would you want to protect your Redis server but not the process which manages it? given that one of the use cases for Sentinel is service discovery, it makes sense to at least minimally protect that service. It is an information sieve as well.

All good points. We can always stick a bird on it by using the same "feel good, but actually insecure" password auth we have now, but it feels like an incomplete implementation of something that should actually be robusto.

Comment From: therealbill

@mattsta Thanks for the technical corrections, it helps to understand what is going on in there :)

Yeah the use of an single key to the kingdom which travels over plain text has always been questionable to me - especially given how fast one could brute force it. Then again user/access management is never easy.

Comment From: therealbill

@mattsta mind tagging this with the "more design needed" label so we can track it via an enhancement proposal I'll work up?

Comment From: antirez

Hello @TheRealBill, today I'm going to create a new issue listing all the stuff we said during the meeting, and each will point to a new issue where the design will be discussed, so we'll have a new Sentinel AUTH issue starting with an analysis of what we can do and the ideas we had during the meeting. Thanks.

Comment From: thestick613

Any updates on that? I've protected my redis instances by password, and i was surprised that i can - perform a failover unauthenticated - start sentinel with requirepass & auth in sentinel is unrecognized.

Comment From: danielsoneg

Any movement on this? If you're curious how an unauth'd sentinel can be used for harm:

% while true; do redis-cli -p 26379 SENTINEL failover redis_test; sleep 2; done
OK
OK
<...>

I know redis's current auth model is - well, let's call it imperfect, but it at least gates some of this behind something more than unprivileged command execution.

Comment From: schlitzered

hey, i also stumbled across this, i think it is would be as useful feature for sentinel to support auth. is there some work going on in this direction?

Comment From: bew

I think that this can be closed, now that sentinel password auth is implemented

Comment From: zedtux

Redis version 6 has not been released so that issue should remain open until a backport is made in the 5 series.