[Feature Request] ACL and Config propagation in Cluster mode

[GraemeMitchell84]

I'm trying to understand how ACL works when using a Redis cluster. From the testing I have done, each node participating in a cluster has it's own independent ACL, and that ACL is not automatically propagated and synced across nodes in the cluster.

For e.g, if I have a cluster with 3 master nodes (node 1, 2 and 3) and 3 replica nodes (node 4, 5 and 6), a user created in node 1 will not automatically be created in nodes 2, 3, 4, 5 and 6?

If it is the case that this is not automatically propagated, I have two questions: -

1. Is the recommended best practice then to have a central "aclfile" which is used by all nodes participating in the cluster. I assume we would then use ACL SAVE on the node the ACL change was made, then use ACL LOAD on every other node in the cluster to sync it?
2. Any plans to add this feature, as I can see this being a nightmare to manage?

[itamarhaber]

Hello @GraemeMitchell84

If it is the case that this is not automatically propagated

That is indeed the case. My interpretation of the reasoning behind this is that ACL is treated similarly to the "regular" configuration (redis.conf) directives. These are also not propagated automatically in a cluster deployment.

1. ...

I, for one, would definitely recommend this practice.

2. ...

No. Maybe. Anything's possible, this really depends on the collective's feedback and need.

That said, I think that the above "best" practice is dead simple and flexible enough. It is just another copy file command in the provisioning script for the node, and/or a rolling ACL LOAD to the cluster's nodes to apply it. The current approach even allows you to relatively easily make a heterogeneous cluster, e.g. restricted users for certain replicas, whereas achieving the same with centralized management would be a harder task.

A Redis geek's afterthought: for more advanced deployments and instead of sharing/schlepping a file, you could if you wanted to, keep an internal standalone Redis instance with all the cluster's ACL definitions (even per node) as a sort of a central permissions directory. Then, in the supporting start script of the cluster's nodes, you can GET and dump it into a local ACL file to load from at bootstrap. You can even use that server's Pub/Sub or Streams for pushing configuration updates to node-side daemons.

[GraemeMitchell84]

Many thanks @itamarhaber for the reply on this one! I wanted to be sure that I wasn't missing something obvious here, i.e. some simple config change or similar that I couldn't see. With regards to suggestions - the users in my case may not be only provisioned at start-up, as users could be added or changed during operation of the cluster without downtime (password policy changes for example). A central process to manage users and distribute those changes (such as pub / sub example you mentioned) would therefore be desirable in my case, coming with the added benefit that it could centrally manage multiple clusters.

I personally see this as a nice value add to avoid people needing to roll their own solution to sync when they simply need to sync this up across the cluster. However, I'm relatively inexperienced in Redis and so perhaps I don't see the full picture and there is not a community need or desire.

[itamarhaber]

Thanks for continuing the dialogue.

However, I'm relatively inexperienced in Redis...

That's exactly why your opinion matters at least as much as my jaded one :) This is a place for discussion and you've raised a good point - I'm hoping to hear more people's thoughts on this.

[madolson]

If we ever implement this, we should probably also consider replicating configs as well.

[itamarhaber]

xref: https://groups.google.com/g/redis-db/c/RCqwd7MStuA/m/xJobGNXjAQAJ

[antoniusostermann]

+1 for any redis-backed solution here. Also, maybe it's a good idea to put a hint in the docs about this? 🤔

[rakeshfromflipkart]

I'm facing a similar situation. My service doesn't manage the Redis instances, instead is responsible for creating users with restricted access. In case of a cluster or master-slave setup the user would be created on a single node and other nodes won't be accessible.

This would result in downtime in case of failover or topology change.

The above mentioned solution also won't work in my case, as we manage only the credentials and not the database itself.