Question
External aclfile vs. CONFIG SET for least-privilege credential rotation
Rey Atlas
0 reputation · 16 Apr 2020, 12:00 UTC
115.3K views1
Loading…
0 reputation · 16 Apr 2020, 12:00 UTC
Implementing a least-privilege security model in Redis 7.0+ requires granular Access Control Lists (ACLs) to restrict users to specific keyspaces and command categories. A primary challenge arises when managing the lifecycle of these credentials, specifically when rotating passwords or updating permissions to prevent credential staleness.
There are two primary methods for managing these identities: maintaining a static aclfile for persistence or utilizing CONFIG SET and ACL SETUSER for dynamic runtime updates. While the aclfile provides a declarative source of truth that survives restarts, runtime updates offer immediate propagation without requiring a file reload.
The uncertainty lies in the trade-off between operational stability and the agility required for automated credential rotation. Using ACL SETUSER dynamically can lead to configuration drift if the external file is not synchronized, whereas relying solely on the aclfile may introduce latency in permission revocation.
ACL SETUSER changes back to a persistent aclfile without manual intervention?To support an automated rotation pipeline without risking permission loss during a restart, the best approach is a hybrid workflow: use ACL SETUSER for immediate runtime propagation, followed immediately by the ACL SAVE command to persist those changes to an external aclfile.
In Redis 7.0+, the ACL SAVE command is the documented method to synchronize runtime changes back to the persistent aclfile. When an external aclfile is defined in redis.conf, Redis treats that file as the source of truth upon startup. However, changes made via ACL SETUSER exist only in memory until they are explicitly flushed to disk.
redisredis.conf contains the aclfile /path/to/users.acl directive.ACL SETUSER command to rotate the password or modify permissions for the target user.ACL SAVE. This writes the current in-memory ACL state to the external file.ACL LIST to confirm the change is active before updating the application's secret manager.| Method | Propagation | Persistence | Risk |
|---|---|---|---|
aclfile only |
Slow (requires reload) | High | Latency in revocation |
SETUSER only |
Instant | None | Loss on restart |
SETUSER + SAVE |
Instant | High | Filesystem write errors |
To verify that your rotation pipeline is persisting correctly, you can run the following sequence in a test environment:
# 1. Change a user password
ACL SETUSER rotation_user >newpassword123
# 2. Persist the change to the aclfile
ACL SAVE
# 3. Restart the Redis service
# (System command: systemctl restart redis)
# 4. Verify the user can still authenticate with the new password
AUTH rotation_user newpassword123Missing Diagnostic Detail: To refine this recommendation, please specify if your Redis instance is running in a clustered environment or as a standalone node, as synchronization across replicas may require additional considerations.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 16 Apr 2020, 12:52 UTC
ACL SETUSERThe answer's hybrid workflow is correct. A practical detail for zero-downtime rotation: ACL SETUSER appuser >newpass appends the new password while keeping the old one active. After confirming all clients have migrated (e.g., via secret-manager rollout), revoke the old credential with ACL SETUSER appuser -oldpass. Run ACL SAVE after each step so the aclfile reflects the intermediate state and survives a restart mid-rotation.
Passwords are stored as SHA-256 hashes in the aclfile (since Redis 6), so plaintext never hits disk. Verify the active credential set anytime with ACL GETUSER appuser.