Redis ACLs – Quick Overview

Implementing

In modern infrastructure, moving away from a single global password to a Role-Based Access Control (RBAC) model is essential. Redis Access Control Lists (ACLs) provide the precision needed to ensure that a service like devops_api_user has exactly the permissions it needs—and nothing more.

1. Anatomy of the Security Policy

When we define a user for a specific API or service, we build a defensive perimeter around that user’s capabilities. Let’s deconstruct the core command:

Bash

ACL SETUSER devops_api_user on >Pr4UmfeLGGJEnBu8zX6VgAYux65C0ide ~user:profile:* +@hash +@read +@write -flushall -flushdb

Why these tokens matter:

  • on: By default, new users are created in a disabled state. This flag is the “master switch” that allows the user to authenticate.
  • >Pr4Umfe...: The > symbol defines the password. Redis stores this as a SHA256 hash, ensuring the cleartext password is never exposed in the configuration files.
  • ~user:profile:*: This is the Key Space Jailing. The user is restricted to keys matching this pattern. Any attempt to access admin:settings or other_app:data will be blocked by the engine.
  • +@hash, +@read, +@write: Instead of listing dozens of individual commands, we use Categories. @read and @write cover standard data operations, while @hash ensures commands like HSET and HGETALL are available.
  • -flushall -flushdb: This is an explicit subtraction. Even if a user has @write permissions, we revoke the ability to wipe the entire database. It’s a safety net against accidental script errors.

2. The Incremental Nature of Permission Stacking

A common misconception is that running ACL SETUSER overwrites previous settings. In Redis, ACLs are strictly incremental. They function like a “patch” to the user’s current state.

If you run:

  1. ACL SETUSER devops_api_user +get
  2. ACL SETUSER devops_api_user +set

The user devops_api_user now has both permissions.

So, if you realize your devops_api_user also needs to handle JSON data, you simply “stack” the new permission:

ACL GETUSER devops_api_user
1) "flags"
 2) 1) "on"
    2) "sanitize-payload"
 3) "passwords"
 4) 1) "3507e38950cdd87d25b568fb4a047edd76ced6de5f61c4cde224a444f3bbf2e6"
 5) "commands"
 6) "-@all +@hash +@read +@write -flushall -flushdb"

Then add the json.set permissiom:

ACL SETUSER devops_api_user +json.set +json.get

When you run ACL GETUSER devops_api_user, you will see that +json.set was simply appended to the existing command string. It did not touch the password or the key patterns previously defined.

ACL GETUSER devops_api_user
 1) "flags"
 2) 1) "on"
    2) "sanitize-payload"
 3) "passwords"
 4) 1) "3507e38950cdd87d25b568fb4a047edd76ced6de5f61c4cde224a444f3bbf2e6"
 5) "commands"
 6) "-@all +@hash +@read +@write -flushall -flushdb +json.set +json.get"

3. Order of Precedence: Left-to-Right Processing

The order in which you write your ACL rules is critical. Redis processes the string from left to right. This is why we grant general categories first and then subtract specific commands.

Correct Example:

ACL SETUSER devops_api_user +@json -json.del
  1. +@json: Grants the user every command in the JSON module.
  2. -json.del: Specifically removes the delete capability from that granted set.

If you reversed this (-json.del +@json), the user would end up with delete permissions because the final +@json would re-enable everything in the category.

4. Hard Resets and Default Security

To completely clear a user’s profile and start from a clean slate, the reset keyword is required. This is the only way to “overwrite” instead of “increment”:

Bash

ACL SETUSER devops_api_user reset on >new_password_123 +@json ~user:*

Furthermore, a professional setup requires securing the two extremities of the access spectrum:

The Superuser (Admin)

For administrative tasks, we create a dedicated user with unrestricted access:

Bash

ACL SETUSER faustobranco on >1234qwer ~* +@all

Neutralizing the Default User

The default user is the biggest security hole in a fresh Redis install. In production, we either disable it or “lock the door” with a high-entropy password:

Bash

# Option A: Kill the default entry
ACL SETUSER default off

# Option B: Set a non-shared, complex password
ACL SETUSER default >ef51306214d9a6361ee1d5b452e6d2bb70dc7ebb85bf9e02c3d4747fb57d6bec

5. Auditing the Effective Policy

The ACL GETUSER command is your primary tool for auditing. It shows the calculated result of all incremental changes:

5) "commands"
6) "-@all +@hash +@read +@write -flushall -flushdb +json.set"

The presence of -@all at the start confirms a “Default Deny” posture: the user starts with zero permissions, and only the items prefixed with + are allowed through the firewall.

More ACLs commands: https://redis.io/docs/latest/commands/acl-list/

List All Users:

ACL LIST
1) "user default on sanitize-payload #0cfd0576db854caea9e711405ba7de4c2fea804e90ecdf7875648ec16cfaa53f ~* &* +@all"
2) "user devops_api_user on sanitize-payload #3507e38950cdd87d25b568fb4a047edd76ced6de5f61c4cde224a444f3bbf2e6 ~user:profile:* resetchannels -@all +@hash +@read +@write -flushall -flushdb +json.set"
3) "user faustobranco on sanitize-payload #ef51306214d9a6361ee1d5b452e6d2bb70dc7ebb85bf9e02c3d4747fb57d6bec #5a973170882744fb97781e2b37942726924ad1245c8def97797ead1c7e028902 ~* resetchannels +@all"

ACL USERS
1) "default"
2) "devops_api_user"
3) "faustobranco"

Who am I?

ACL WHOAMI
"faustobranco"
JSON Document Management in Redis

JSON Document Management in Redis

Implementation of a first example of a Resilient Cache-Aside Layer with Redis and PostgreSQL.

Implementation of a first example of a Resilient Cache-Aside Layer with Redis and PostgreSQL.