Redis / Valkey security hardening (ACL, TLS, dangerous commands)

Not an installation or day-to-day operations guide: a scenario-based runbook for hardening a running Redis or Valkey (single server, replica + Sentinel or Cluster) without downtime. Read-only security audit, ACL users and disabling the default user, requirepass/masterauth, bind and protected-mode, protected configs against CONFIG/DEBUG/MODULE abuse, online migration to TLS (clients, replication, Sentinel, cluster bus) and file permissions; at the end the audit is repeated to show that the risks are closed. Systems built with the DBAtlas installation guides already have a password and a narrow firewall: start with the audit and apply only the scenarios that report RISK or WARN. Backup and day-to-day operations are in separate Redis guides.

Topology: Single server, master + replica + Sentinel, or Redis Cluster

Scenarios

• Security status audit (read-only) — Changes nothing. Passwordless access, the default user, listening addresses, protected-mode, dangerous commands, TLS, the Sentinel password and file permissions are reported as OK / WARN / RISK. Choose this if you do not know where to start.
• Full hardening (all in order) — Audit → ACL users (admin, application, replication, Sentinel) and disabling the default user → bind/protected-mode/firewall → dangerous commands and protected configs → TLS → file permissions → final audit. Rolling on replicas/Sentinel; risky steps ask for confirmation.
• ACL users and disabling the default user (Redis 6+) — Everyone connects as the default user with a single password (or none). Separate users are created for the administrator, the application (its own keys only, no dangerous commands), replication and Sentinel, written to the aclfile, and once the applications have moved, default is disabled.
• Redis without a password: requirepass / masterauth (quick fix) — There is no password at all and no time to move to ACL. A shared password is set online on all nodes (requirepass + masterauth for replication, auth-pass for Sentinel); applications can no longer connect without a password.
• Restrict network access (bind 0.0.0.0, protected-mode, firewall) — Redis listens on all interfaces or runs with protected-mode no. bind is reduced to localhost + the internal IP, protected-mode is enabled, and the firewall allows only the nodes and the application network. Applied online, existing connections are not dropped; this is the step that lowers the risk fastest.
• Dangerous commands and CONFIG abuse (FLUSHALL, CONFIG, DEBUG, MODULE) — Against abuse of CONFIG SET dir/dbfilename to write files on the server (SSH key, cron) and against FLUSHALL/DEBUG/MODULE LOAD: enable-protected-configs, enable-debug-command, enable-module-command are kept disabled and @dangerous is removed from applications; on older versions rename-command.
• Encrypt connections: TLS (clients, replication, Sentinel, cluster bus) — Traffic is unencrypted. The TLS port is opened online next to the existing port, replication and Sentinel move to TLS, and once the applications have switched, the plaintext port is closed (port 0).
• File permissions and service user — redis.conf (contains passwords), the ACL file, RDB/AOF and log files are readable by other users, or Redis runs as root. Permissions are tightened to 640/750 and ownership is set to the service user.

Before you start

• root/sudo on all nodes; SSH from the first node to the others (copying the password file and certificates).
• Redis 6.2+ or Valkey 7.2+ (6.0+ for ACL, 7.0+ for protected configs).
• Replication… and Sentinel… are healthy; rolling operations are not performed on an unhealthy topology.
• List of applications and client library versions: username + password for ACL (Redis 6+ client), rediss:// support for TLS; for clients using Sentinel, Sentinel password and TLS support.
• openssl is installed (password and certificate generation).

Phases of the guide

• Preparation: safety net and helper tools — Configuration and ACL backup · Write the helper tools (dbatlas-rconf, dbatlas-rcli, dbatlas-redis-restart) · Write the admin password to a temporary file
• Status audit (read-only) — Security report: … · Sentinel report: … · Map the findings to scenarios
• Password: requirepass and masterauth (online) — Set the shared password: … · masterauth: … · Sentinel auth-pass: … · requirepass: … · Password for Sentinel: … · Are replication and Sentinel healthy …
• ACL: diagnosis and user passwords — Diagnosis: who is connected with which user? · Generate the internal user passwords · Copy the password file to the other nodes
• ACL: disable the default user — Any clients left connected as default: … · Disable the default user: … · Verify: unauthenticated access, application privileges, replication · Password for Sentinel: …
• Network access: firewall — Firewall rules
• Dangerous commands: diagnosis — Protected configs and debug/module commands: …
• Dangerous commands: verification — Are CONFIG SET dir and DEBUG rejected: …
• TLS: certificates — TLS support: … · Generate the internal CA and server certificates · Distribute the certificates · Certificate permissions: …
• TLS · Cluster bus and replication (maintenance window, all nodes together) — Pin the bus port, write tls-cluster and tls-replication to the file: … · Stop: … · Start: … · Are cluster and replication on TLS
• TLS: verification and closing the plaintext port — Are replication… and Sentinel… on TLS · Close the plaintext port: … · Is the unencrypted connection rejected: …
• File permissions and service user — Fix permissions: …
• Final audit (after hardening) — Security report: … (final state) · Sentinel report: … (final state)
• Cleanup and follow-up — Delete the temporary password files · Follow-up: monitoring and periodic tasks