Using Redis ACL Categories and Command Restrictions in Practice

1. Why a single password no longer works for modern setups

Before Redis 6, the server essentially knew one authentication secret through requirepass, which granted either full access or none at all. For a single application with a single connection source, that was sufficient, but modern architectures rarely consist of just one service: a Magento store uses Redis in parallel for the full page cache, for sessions, for the object cache, and often for queues or indexer locks as well.

If all these services share the same password, a compromised cache client could theoretically also read other users' sessions or, worst case, wipe the entire dataset with FLUSHALL. The Access Control List system from Redis 6 solves this by allowing a dedicated user per service with precisely tailored permissions, instead of a single master password for everything.

2. ACL categories at a glance

Instead of enabling each of the several hundred Redis commands individually, Redis groups commands into predefined categories that can be enabled or blocked with a single expression. The most important ones include @read for read operations, @write for write operations, @keyspace for commands affecting the entire keyspace, @admin for administrative operations like CONFIG or CLIENT KILL, and @dangerous for commands with especially far-reaching effects such as FLUSHALL, SHUTDOWN, or DEBUG.

The full list of all categories and their assigned commands can be queried at any time via the ACL CAT command, while ACL CAT followed by a category name lists the specific commands inside that category. This transparency matters because categories occasionally expand with newly added commands in new Redis versions, so an existing permission setup should be checked regularly against the current category list.

# Inspect all available categories and their commands
redis-cli ACL CAT
redis-cli ACL CAT dangerous

3. A practical least-privilege setup per application service

The core idea of least privilege is to give each service only the permissions it actually needs for its concrete task, never more. A cache read service that only reads product data and never writes itself should get only @read permissions on its own key prefix, while a separate cache warmer process additionally needs @write for exactly the same prefix, but still no administrative rights whatsoever.

In practice, such a user is created via the ACL SETUSER command, which combines categories, individual command exceptions, and key patterns in a single rule. A session service, for example, needs read and write access on its session prefix as well as the EXPIRE command to set expiration times, but neither access to other services' cache keys nor to administrative commands.

# Cache reader: read only, own prefix only
redis-cli ACL SETUSER cache-reader on >strong-password \
  ~cache:* +@read

# Cache warmer: read and write, but no admin rights
redis-cli ACL SETUSER cache-warmer on >another-password \
  ~cache:* +@read +@write -@admin -@dangerous

4. Handling dangerous commands in production

Commands like FLUSHALL, FLUSHDB, or KEYS belong to the @dangerous category and should be explicitly blocked in nearly every production application connection. FLUSHALL and FLUSHDB irreversibly delete all data of the instance or a database respectively, while KEYS blockingly scans the entire keyspace on a large dataset, noticeably slowing down the instance for every other client.

For administrative tools and maintenance scripts that genuinely need these commands, a separate, closely monitored administrator user is recommended, clearly distinct from the application services, with credentials that do not live in the same configuration file as the regular services. For ad-hoc diagnostics, the non-blocking SCAN command should generally be used instead of KEYS, walking the keyspace in small chunks without blocking the instance for other clients.

5. ACL file versus runtime configuration and their persistence

Users created via ACL SETUSER initially exist only in the running instance's memory and are lost on a restart without further action. For a durable setup, there are two paths: either a separate aclfile that is loaded at server startup and contains all user definitions as text, or the ACL SAVE command, which writes the rules currently active in memory back into exactly that file.

For production environments, the aclfile is recommended as the source of truth, ideally kept under version control so every permission change is traceably documented. Runtime changes via ACL SETUSER are then mainly suited for emergency adjustments, such as immediately locking out a compromised user, followed by an ACL SAVE to persist the change into the file permanently.

6. Key pattern restrictions combined with command categories

Command categories alone only control which commands a user may run, not which keys. Only combining them with key pattern rules, introduced by the tilde character, additionally restricts access to a specific namespace. A user with +@read and the pattern ~session:* may read, but exclusively within keys starting with session:, even if other keys theoretically exist in the same database.

This combination of command and keyspace restriction is decisive in multi-service setups, because it prevents a compromised cache service from accessing session data, even when both services share the same Redis instance and the same logical database. Without such keyspace separation, plain command restriction alone would only be half a defense.

# Strictly limit access to one key prefix
redis-cli ACL SETUSER session-service on >password \
  ~session:* +@read +@write +expire -@dangerous

7. Testing and auditing ACL rules

Before putting a new user into production, it is worth explicitly testing the actual permissions via ACL WHOAMI to identify the active connection, and ACL GETUSER for a given username, which outputs the complete, effective permission configuration including all categories and key patterns. This check pays off especially for more complex rules with several added and subtracted categories, since rule order affects the final result.

For a regular audit of all existing users, ACL LIST is the right tool, printing every active rule in plain text and integrating well into an automated script that flags deviations from an expected target configuration. Such an audit reliably catches a case where an overly broad permission was accidentally granted, for example +@all instead of the actually intended narrow category.

8. Migrating from requirepass to ACL without downtime

An existing installation still running on classic requirepass can be migrated to ACL gradually without interrupting operations. The default user stays active with its previous password for the time being, while new, restricted users are created in parallel for each application service. Only once every service has successfully switched to its own user is the default user either disabled or reduced to a pure emergency account with heavily restricted permissions.

This gradual approach allows each service migration to be tested individually and immediately falls back to the old password if something goes wrong, instead of switching the entire infrastructure over in one risky cut. For Magento environments, that concretely means migrating the cache, session, and indexer connections one after another to their own ACL user, confirming each migration with a production test run before the next service follows.

9. Practical example: a multi-service setup in a Magento store

A realistic Magento setup typically uses Redis for several clearly separated purposes at once: the full page cache, the object cache, sessions, and often a queue for asynchronous indexer runs as well. In the ACL model, each of these purposes gets its own user with exactly the categories and key prefixes needed for that task, and nothing beyond it.

Such a setup noticeably limits the damage of a compromised application server: even if attackers gain access to the cache credentials through an application vulnerability, other users' session data and the indexer queue remain unreachable thanks to the separate users and key prefixes. This isolation can be retrofitted into an existing installation without a fundamental rebuild of the application, as long as the connection configuration is already separated per service.

10. Summary

11. FAQ: ACL Categories in Redis: Key Takeaways