HowToCodePage

Security: ACLs, TLS and hardening

ACL users with key and command patterns, TLS configuration, disabling dangerous commands, protected mode, and network isolation.

ACLs

# an application user limited to its own key prefix and a small command set
ACL SETUSER app_reader on >password ~cache:* +@read +@connection -keys -flushall
ACL SETUSER app_writer on >password ~cache:* ~lock:* +@read +@write -@dangerous

# a worker that only touches stream keys
ACL SETUSER worker on >password %R~events:* %W~events:* +xreadgroup +xack +xadd +xautoclaim

# a read-only replica client
ACL SETUSER reporting on >password ~* +@read -@write

ACL LIST
ACL GETUSER app_writer
ACL WHOAMI
ACL LOG 10                 # rejected commands, with the reason
ACL CAT dangerous          # the command categories to exclude
  • The pattern syntax supports ~key*, %R~ for read-only key patterns and %W~ for write-only, which is how a worker gets exactly what it needs.
  • +@read and -@dangerous express intent better than listing commands, and they keep working when new commands are added.
  • Never leave the default user enabled without a password. A running server with a reachable port and no authentication is compromised within hours on a public address.
  • ACL LOG is a security signal, not just a debugging aid - alert on a spike in denials.
⚠️
Disabling a command in the configuration is not enough on its own: CONFIG SET can re-enable it, and MULTI plus EVAL can reach behaviour indirectly. Use ACLs to remove the permission, restructure the command at the server, and keep the instance off the public network.

TLS and transport

# redis.conf
port 0
tls-port 6379
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file  /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-auth-clients yes
tls-protocols "TLSv1.2 TLSv1.3"
tls-ciphersuites TLS_AES_256_GCM_SHA384

requirepass     # avoid; prefer per-user ACLs in aclfile
aclfile /etc/redis/users.acl
protected-mode yes
rename-command FLUSHALL ""
redis-cli --tls --cacert /etc/redis/tls/ca.crt \
  --cert /etc/redis/tls/client.crt --key /etc/redis/tls/client.key \
  -h redis.internal -p 6379 PING
  • port 0 with only tls-port set is the strongest transport configuration: the plaintext port does not exist to be misconfigured.
  • tls-auth-clients yes requires a client certificate, which turns a stolen password into a useless credential without the key.
  • TLS adds a round trip on connection setup, so connection pooling matters more, not less.
  • Cluster bus and replication links need their own TLS settings; a secure client connection with an unencrypted replication link is only half protected.

Network and operational hardening

  • Bind to a private interface or a Unix socket and never publish the port to the internet. A firewall rule is not a substitute for a bind address.
  • protected-mode yes refuses connections from non-loopback addresses when no password is set; it is a safety net, not a security model.
  • Run Redis as a dedicated unprivileged user with a configuration file that the application user cannot write to.
  • Consider a separate instance per trust boundary. Two applications sharing one instance share every key, every ACL mistake and every latency spike.
  • Keep the server patched. Recent critical issues have been remotely exploitable in scripts and modules, and the fix is usually a version bump.
  • Never run MONITOR, KEYS or FLUSHALL from an automated job in production; rename or remove them where they are not needed.
# verify what is exposed before you ship
ss -ltnp | grep redis
redis-cli ACL WHOAMI
redis-cli CONFIG GET bind
redis-cli CONFIG GET requirepass
redis-cli INFO server | grep -E "redis_version|config_file"

FAQ

Is a password enough?
No. Use per-application ACL users with key patterns and command categories, require TLS, and keep the instance on a private network. A single shared password means one leaked credential exposes every key and every command.
How do I rotate a credential without downtime?
Add the new user alongside the old one, deploy the clients, verify with ACL LOG that the old user is idle, then delete it. Never overwrite a password in place on a live system.

Key design, memory and eviction Replication, Sentinel and high availability

Last refreshed 2026-09-18.