Allowing untrusted clients read-only replication of public data in a redis instance?

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.