Only partly. Redis ACL key patterns restrict commands that name specific keys, but commands that take no key arguments, such as FLUSHALL, FLUSHDB and SWAPDB, are governed by command rules only. A user limited to tenant1 keys can still delete everything unless you deny those commands. For hard isolation, use separate instances.
What the documentation says
The Redis ACL documentation is direct about this. Key patterns only restrict commands that operate on specific keys named in the command's arguments. Commands that operate on an entire database or the whole keyspace, and therefore take no key arguments, are not limited by key patterns. The documentation gives the example of a user defined with a tenant1 key pattern and all commands, who can still run FLUSHALL to delete every key in the database. Its fix is to remove those commands explicitly.
Two other details matter for multi-tenant designs. From Redis 7.0 you can set read and write permissions per key pattern. And some commands read one key and write another, so a rule set must cover both source and destination.
Isolation options compared
| Approach | Strength | Weakness |
|---|---|---|
| Key prefix per tenant, enforced by ACL patterns | Cheap, simple | Whole-keyspace commands, shared memory and shared CPU |
| Prefix plus denied dangerous commands | Closes the FLUSHALL gap | Still a shared instance, so one tenant's load affects others |
| Separate instance per tenant or per sensitivity class | Strong boundary | More to run and patch |
| Application-level tenant checks only | Flexible | A single bug can cross tenants |
The third row is advice rather than a documented rule. If a tenant's data is sensitive enough that cross-tenant access would be a serious incident, a separate instance is the clearer boundary.
Steps
- Choose a key naming rule that puts the tenant or application first, such as a short prefix and a colon.
- Create a user per tenant or service with a key pattern for its prefix, for example the pattern tenant1 colon star.
- Deny whole-keyspace commands. The documentation's example adds minus flushall and minus flushdb to the user's rules, and you should consider swapdb and the dangerous category too. Check the contents of the category on your version with ACL CAT.
- Use read-only permissions where a service only reads another service's data, with the percent R tilde form from Redis 7.0.
- Test as that user. Try to read another tenant's key, write one, and run FLUSHALL. All three should fail.
- Watch for commands that do not name keys but still reveal or change shared state, and review them against your own risk. The documentation says that if an application must prevent any data access from a key, including side channels, it should grant no access to the key.
- Document the isolation model so reviewers know what it does and does not promise.
Do not forget the default user
None of this helps if connections can authenticate as the default user, which in a fresh install can run every command on every key. See Redis ACL users: replace the default user nopass.
Noisy neighbours are a security issue too
Even with perfect key isolation, tenants share memory and CPU. One tenant filling memory or running slow commands can degrade or evict another's data. Plan memory limits and eviction behavior deliberately, or isolate large tenants.
Safeguard's policies and gates can check configuration changes in pull requests, and the free scan covers your dependencies.
Quick check
Does a key pattern stop a user from running KEYS or SCAN on the whole database?
The documentation says commands with no key arguments are governed only by command and category rules. Test the specific commands you care about on your version, and deny them if needed.
Is a separate Redis instance per tenant always required?
No. It depends on how bad cross-tenant exposure would be. For lower sensitivity data, prefixes with denied dangerous commands may be acceptable if you test them.
Sources
Last reviewed: 19 October 2026.
