18 lines
1.3 KiB
Markdown
18 lines
1.3 KiB
Markdown
# ACL accounts
|
||
|
||
One file per `CommandAccess` level. Each account is deliberately narrower than the SDK's own rules:
|
||
the account is the last enforcement boundary and a permit issued inside the process never widens it,
|
||
so a mistake in the SDK is still refused by the server.
|
||
|
||
A Redis ACL file accepts nothing but complete `user` lines — no comments and no line continuations —
|
||
which is why the rationale lives here instead of inline. Password material is supplied at deploy
|
||
time; none of these files carries one.
|
||
|
||
| File | Account | Grants |
|
||
| --- | --- | --- |
|
||
| `application.acl` | `CommandAccess.APPLICATION` | the typed data-structure commands over `prod:*`, with the dangerous and deprecated names denied |
|
||
| `application-advanced.acl` | `APPLICATION_ADVANCED` | the above plus pub/sub, transactions, and the registered-script path. `EVAL` is absent: only `EVALSHA` of an already loaded digest is reachable |
|
||
| `raw-gateway.acl` | `RAW_GATEWAY` | exactly the commands the catalog classifies `RAW_ONLY`, and nothing else |
|
||
| `all-accounts.acl` | – | the four accounts concatenated; Redis takes one `aclfile`, so this is what a deployment loads |
|
||
| `admin-readonly.acl` | `ADMIN_READONLY` | read-only diagnostics. Every destructive counterpart is denied here and blocked in the command policy catalog — two independent controls for the same rule |
|