How do you restrict Redis Pub/Sub channels with ACL rules?

From Redis 6.2, ACL rules can limit which Pub/Sub channels a user may publish to or subscribe to, using an ampersand followed by a glob pattern. Start from resetchannels, add only the channel patterns an application needs, and remember that PSUBSCRIBE needs a literal match with the allowed patterns.

Why channels need rules

Many applications use Redis Pub/Sub as a lightweight message bus: notifications, cache invalidation, job signals. By default, every connection belongs to the default user, which the ACL documentation shows as having access to all keys, all channels and all commands. Any client that connects can subscribe to any channel and read every message, or publish to any channel and trigger other services.

If channel names carry user identifiers, or messages hold order details, that is a data exposure problem. If a service acts on a message without verifying its origin, it is an injection problem. Both go away if each service can only touch the channels it owns.

The rules

The Redis ACL documentation defines these channel rules:

Pattern matching applies to channels named in PUBLISH and SUBSCRIBE. PSUBSCRIBE is stricter: it requires a literal match between the channel patterns the client asks for and the patterns allowed for the user. A user allowed orders colon star can subscribe to the pattern orders colon star, but not to a broader pattern.

Steps

1. Inventory channels. Search code for PUBLISH, SUBSCRIBE and PSUBSCRIBE calls and write down who publishes and who subscribes on each channel.
2. Create one user per service. Generate passwords with ACL GENPASS, as covered in How do you block dangerous Redis commands.
3. Give each user resetchannels, then add the patterns it needs.
4. Keep publish and subscribe roles apart where you can. A service that only listens for invalidation messages should not be able to publish them.
5. Restrict the commands as well. Channel rules limit which channels, and command rules limit what else the user can do.
6. Apply the rules, then test that an unauthorised subscribe or publish is rejected.
7. Update or disable the default user, since its default settings permit everything. See Redis ACL users: replace the default user nopass.

An example rule for a service that listens on invalidation channels and nothing else:

ACL SETUSER invalidator on >replace-with-generated-password resetchannels &invalidate:* resetkeys -@all +subscribe +ping

Test it against your Redis version before use. Command names and categories can differ, and you should confirm what the user needs with a staging run.

A word of caution on guarantees

Channel ACLs control who may connect to a channel. They do not verify the content of messages, and Redis Pub/Sub does not store messages for later. A subscriber that was offline when a message was published misses it. If you need durability or replay, you are in the territory of streams or a dedicated broker, and the security questions change with them.

Still validate in the consumer

Treat every message as input. Parse with a strict schema, reject unexpected fields, and never build code or queries from message text. The Redis security documentation notes the Redis protocol itself has no string escaping problem, but what your consumer does with the payload is on you.

Safeguard's policies can review configuration changes in pull requests, and its SBOM and dependency scanning list the Redis client libraries your services use. The free scan is a quick way to look.

Quick check

Sources

• Redis Access Control List
• Redis security

Last reviewed: 19 October 2026.