Issue
Without any kind of ACLs, it's anywhere from difficult to impossible to prevent clients from writing directly to master redis server, instead of using API that keeps an audit log, implements additional ACLs, etc.. In certain cases, a local system has a read-only slave running to provide faster access to data stored in Redis, but some users/eng, when need to write data would connect to master directly bypassing an API. Enabling AUTH could help, ensuring proper read permissions on config file (setting 0440 /etc/redis/redis.conf, for example), but AUTH password could end up being available to Eng via source control or local code. Some may suggest using local commits/changes for sensitive passwords, but it's not that convenient.
Current Workaround
Using AUTH on master-to-slave and master-to-rw-client and no AUTH for slaves-to-ro-client, making sure the AUTH password is not available in source control and could not be read by Eng having terminal access to systems running API or other services having RW access.
Proposed Solution
By having slave-to-master sync only (RO) port vs. full access (RW) port, would eliminate the need for more expensive AUTH (if you are to choose AUTH based RW vs RO split) and would allow to use simple network layer ACLs for more flexible configuration. Bind to both when more than one are set,
Comment From: mezzatto
Just create a "internal network" where you Redis / Application communicate. In AWS, create a VPC with you EC2 instances with 2 subnets / interfaces per instance. Then you can configure the ACL on these subnets as you like.
Comment From: anapsix
hey @mezzatto, thanks for the suggestion. using different networks will work, when users do not have access to the machine local read-only slave is running on.. but when users do have an ssh access there, nothing would prevent them from using this additional network for direct access to master..
Comment From: elreydetodo
I'm working in a situation where our redis master instance is on an semi-trusted network. We have some cron jobs automatedly updating various keys and it's a free-for-all when it comes to reading. The problem is I've got one user who I call "Rooty" who likes to exploit things like an open Redis master for any number of things that I don't want him to do. He has access to the network, but not to any machine that I would trust to be making changes.
I think making one read-only and one read-write port available is a reasonable security mechanism. It creates some isolation, it makes admin-enforceable read-only connections available, and it allows for network-based firewalling without disrupting slave replication.
Comment From: anapsix
closing due to age, and ACL and AUTH implementation available in latest versions