I've got a database of publicly auditable votes, updated in real time in a redis instance. Nothing else is in that redis instance. It has been separated from related data in a second redis instance. Although I can expose it to the internet with the bind directive, AFAIK that won't work since there is no way to permit write operations based on the source IP being localhost without also permitting others on that bind the same access.
I could create a third redis instance, replicating locally (hence securely) for the sole purpose of providing a replicable audit instance, and then expose that instance to the public IP address in its bind directive. However, according to the "Read-ony replica" documentation, this won't be enough due to the following passage:
Read-only replicas will reject all write commands, so that it is not
possible to write to a replica because of a mistake. This does not
mean that the feature is intended to expose a replica instance to the
internet or more generally to a network where untrusted clients exist,
because administrative commands like [emphasis JAB] DEBUG or CONFIG are still
enabled. The Security page describes how to secure a Redis instance.
The Security page offers a promising approach to patching these commands:
Disabling of specific commands It is possible to disable commands in
Redis or to rename them into an unguessable name, so that normal
clients are limited to a specified set of commands.
For instance, a virtualized server provider may offer a managed Redis
instance service. In this context, normal users should probably not be
able to call the Redis CONFIG command to alter the configuration of
the instance, but the systems that provide and remove instances should
be able to do so.
In this case, it is possible to either rename or completely shadow
commands from the command table. This feature is available as a
statement that can be used inside the redis.conf configuration file.
For example:
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 In the
above example, the CONFIG command was renamed into an unguessable
name. It is also possible to completely disable it (or any other
command) by renaming it to the empty string, like in the following
example:
rename-command CONFIG ""
However the afore-emphasized word "like" leaves me wondering what else might be left open to untrusted clients by this third redis instance. Moreover, since the sole purpose of this instance is to provide real-time replication of data to the auditing public, the set of commands that should be disabled are all those not essential to the local replication from the source instance and global replication to auditing instances.
