In order to restrict redis-sentinel access to specific clients, redis-sentinel supports the requirepass configuration parameter. This means clients must provide the required password before issuing commands such as SENTINEL get-master-addr-by-name.
However, a problem arises when you want to prevent those clients from adding or removing monitored masters (i.e., SENTINEL remove mymaster) but still allow a system administrator to do so.
I propose enabling configuration of ACLs for redis-sentinel, similar to how redis-server allows for ACL configuration with multiple users. Sentinel could then be configured with, for example,
user default on nopass ~* -@all +SENTINEL|get-master-addr-by-name
user sentinel on >super_secret_passw0rd ~* +@all
user admin on >super_secret_passw0rd2 ~* +@all
and this would prevent regular clients from modifying the sentinel configuration while still allowing them to properly retrieve the current master address.
Additional configuration values could be provided in order to specify how redis-sentinel should authenticate with other sentinel instances. For example,
sentinel-user sentinel
sentinel-pass super_secret_passw0rd
Comment From: zkewlguy
I would like to bump this request. It appears to me that using ACLs on Redis Server to set a username and password, but not setting "requirepass" would allow a smooth transition from unauthenticated to authenticated clients. Clients using AUTH and clients not using AUTH connecting to Redis Server still work. Once all clients are transitioned over, then setting "requirepass" would lock it down as desired.
Sentinel only supports requirepass. As far as I know there is no way to avoid a blip during the same process. Thank you.