The problem/use-case that the feature addresses

In a microservice environment we may have many clients connecting to the same Redis instance. Due to ACL we may now let these clients have restricted access to their own namespaces for stored data, but we can not give them access to pub/sub without giving them the possibility to interfere with eachother.

Description of the feature

It should be possible to allow users pub/sub access to only certain channels, similarly to how we restrict access to keys

Alternatives you've considered

  • Have seperate Redis instances for clients that should communicate
  • Allow clients to interfere with eachother
  • Use non-redis pub/sub features

Additional information I couldn't find any information regarding this feature or whether it has been discussed before

Comment From: yossigo

@asleire Thanks for the report. We'll need to consider if/how this should be resolved. The naive approach could be to apply ACL key specifications to channel names, however: 1. This would not be backwards compatible. 2. That may not play well with patterns.

The other approach could be to extend ACLs to specify channel names. @redis/core-team Any other thoughts here? Perhaps this should be considered at the time we get to do some major ACL work (like #7291).

Comment From: oranagra

It seems like a trivial small step forward. I suppose it should use a different modifier prefix than ~, which will avoid breaking backwards compatibility.

Not sure we need to wait for a big revolution in ACL in order to add that feature.

@yossigo The patterns problem you're referring to is the subscribe patters, right? that seems like a complicated issue indeed. maybe we should permit a subscription only if the subscribed pattern exactly matches the ACL rule pattern. i.e. ACL subscription pattern controls the publish and subscribe (when used without pattern) normally (allowed if pattern matches the channel name). if the subscriber uses a pattern, it is allowed only if it exactly matches an ACL pattern.

Comment From: itamarhaber

Heya @asleire

I had an urge to jump on this one (I think because someone once told me that I'm not a systems dev and I've been fighting myself about that ever since ;)) and take a stab at a draft implementation. Please feel free to review/test #7993.