A read-only reporting user
Grants come before revocations, which is what makes it restrictive
- username
- reporting
- key-pattern
- metrics:*
- access
- read
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.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
Grants come before revocations, which is what makes it restrictive
+@all then -@dangerous, in that order and not the other
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
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.
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.
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.
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 > 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.
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.
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.
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.