A read-only reporting user
Grants come before revocations, which is what makes it restrictive
- username
- reporting
- key-pattern
- metrics:*
- access
- read
Redis ACL Generator
Describe what an application needs and get an ACL SETUSER rule. Rules apply strictly left to right, so the order matters more than the contents: the same words in the other order produce a superuser.
users.acl
updates as you typeExamples
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
An admin that is not a superuser
+@all then -@dangerous, in that order and not the other
- username
- ops
- key-pattern
- *
- access
- admin
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Writing -@dangerous before +@all
Rules apply left to right, so the revocation happens to a user with no permissions and the grant then hands back everything. The result is a superuser that reads like a restricted account.
Instead:Grant first, revoke second.
Using the > form with a clear-text password
The password ends up in the config file, in shell history and in any log that captured the command.
Instead:Use the # form with a SHA-256 hash.
Granting a key pattern but no commands
The user authenticates and then fails every call, which looks like a network or client fault rather than a permissions one.
Instead:Grant both, and test with the real application.
Assuming ~pattern covers pub/sub channels
Channels use &pattern and are tracked separately. From Redis 7 the default is no channels at all.
Instead:Add &pattern explicitly if the user subscribes.
Why the order of an ACL rule decides what it means
ACL rules are not a set of permissions. They are a sequence of instructions applied left to right, and that is the source of nearly every ACL that does not do what its author intended.
+@all -@dangerous and -@dangerous +@all are opposites
The first grants everything then takes the dangerous commands back. The second removes dangerous commands from a user who has none, then grants everything, including the ones just removed. Nothing warns about the second, and ACL GETUSER shows the resulting permissions rather than the mistake.
The password is stored as a hash, and should be supplied as one
The > form takes clear text, which then lives in the config file, in shell history and in any log that captured the command. The # form takes a SHA-256 hash and never exposes the original. ACL GETUSER shows existing hashes, so an existing user can be moved without knowing the password.
A user with no key pattern can read nothing
The default is no access at all rather than full access, which is the right way round. It also means a rule that grants commands but forgets ~pattern produces a user that authenticates successfully and then fails every command, which reads like a broken connection.
Channels are separate from keys
Pub/sub permissions use &pattern and are not covered by ~pattern. Before Redis 7 the default was all channels; from Redis 7 it is none. A rule written against the old default silently loses pub/sub access on upgrade.
What this cannot check
It cannot see your keyspace, so it cannot tell you whether the pattern matches the keys the application actually uses. Test the rule with the real application before it reaches production, because an ACL failure looks like an application bug.
Related redis tools
Redis ACL Rule Decoder What does this user actually get? Redis ACL Validator Find the rule that does nothing Redis Config File Generator A redis.conf with the reasons in it Redis Maxmemory Config Generator The limit, and the headroom it needs Redis Persistence Config Generator How much you can afford to lose Redis Lua Script Generator Atomic, and short enough to stay that way
All 53 redis tools