Security: ACLs, TLS, Network Isolation

In one line

Redis must never be reachable from untrusted networks. Layer defences: private networking and firewalls, protected mode, per-service ACL users with least privilege (key patterns and command categories), TLS in transit, managed secrets, protected configs, encrypted backups, and fast patching.

0/5 · 0%

Think of it like this

A bank vault. It's inside the building (private network), behind a locked door (authentication), different staff can open different drawers (ACLs by key pattern), only managers can change the locks (admin commands restricted), and cash moves in locked cases (TLS).

Key ideas

01
The main historical risk: Redis instances exposed to the internet without a password. Attackers found them by scanning and abused administrative commands (for example rewriting configuration to write files onto the host, or loading modules) to take over servers, or simply wiped or ransomed the data. protected-mode yes (default since 3.2) refuses external connections when no password is set, but binding to public interfaces with a weak password is still dangerous.
02
Network first: bind to private interfaces (bind 10.0.1.5), put Redis in private subnets, allow only application security groups on 6379 (and 16379 for the cluster bus), and never expose it publicly.
03
ACLs (Redis 6+): create a user per service with only the keys and commands it needs: ACL SETUSER checkout on >secret ~checkout:* ~{cart:* +@read +@write -@dangerous. Disable or lock down the default user. Separate admin users for operations, with +@admin only for them. Use ACL LOG to see denied commands and ACL DRYRUN to test.
04
Dangerous commands for app users: FLUSHALL, FLUSHDB, CONFIG, DEBUG, KEYS, MODULE, SHUTDOWN, REPLICAOF, MIGRATE, SCRIPT/FUNCTION management. Redis 7 also adds enable-protected-configs, enable-debug-command and enable-module-command (defaulting to no or local-only) so these can't be changed or used remotely even by privileged users. ACLs replace the old rename-command trick.
05
TLS: tls-port 6379, port 0 (disable plaintext), certificates for server and optionally clients (mutual TLS), and TLS on replication and the cluster bus (tls-replication yes, tls-cluster yes). TLS costs CPU; I/O threads help.
06
Secrets and data: passwords from a secret manager with rotation (ACLs allow multiple passwords per user for zero-downtime rotation), encryption at rest where available (managed services), encrypted and access-controlled backups (RDB files contain everything), and avoid storing unnecessary personal data in Redis.
07
Patching: Redis has had serious vulnerabilities, including in the embedded Lua engine (for example CVE-2025-49844, a use-after-free fixed in October 2025 releases). Most require an authenticated connection, which is why network isolation and least-privilege ACLs matter so much. Track advisories and upgrade promptly.

Code & diagrams

acl.redisredis

# Lock down the default user, create least-privilege service users
ACL SETUSER default off
ACL SETUSER admin on >***admin-secret*** ~* &* +@all
ACL SETUSER checkout on >***checkout-secret*** ~checkout:* ~{cart:* +@read +@write +@connection -@dangerous
ACL SETUSER reporting on >***report-secret*** ~report:* +@read -@dangerous
ACL SETUSER exporter on >***exporter-secret*** +client +ping +info +config|get +cluster|info +slowlog +latency +memory -@dangerous

127.0.0.1:6379> AUTH checkout ***checkout-secret***
OK
127.0.0.1:6379> FLUSHALL
(error) NOPERM User checkout has no permissions to run the 'flushall' command
127.0.0.1:6379> GET orders:1
(error) NOPERM No permissions to access a key
127.0.0.1:6379> ACL LOG 1
1) 1) "count" 2) (integer) 1 3) "reason" 4) "key" ... "object" "orders:1" "username" "checkout"

redis.conf (security)text

bind 10.0.1.5 127.0.0.1
protected-mode yes
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-replication yes
tls-cluster yes
aclfile /etc/redis/users.acl
enable-protected-configs no
enable-debug-command no
enable-module-command no
rename-command ""   # (legacy) prefer ACLs

Interview problem

The problem

An attacker gets network access to Redis

Assume an attacker gains network access to your Redis (for example via a compromised pod in the same VPC). What prevents them from running FLUSHALL, CONFIG SET, DEBUG and other administrative operations? Describe the defensive layers and how you'd detect the attempt.

The interviewer follows up

Is requirepass enough?

When it breaks

Redis bound to 0.0.0.0 on a cloud VM with a public IP and a weak password

What you see

Internet scanners find it within hours; data is wiped or ransomed, or the host is compromised.

Fix & prevent

Private subnets only, firewall rules, strong ACLs, TLS; verify exposure with an external port scan and cloud security posture tools.

Explain it without notes

Explain defence in depth for Redis in four layers.

Practice

Create an ACL user for one service in your lab that can only read and write svc:* keys, and verify it can't run KEYS, FLUSHALL or read other prefixes.

Trade-offs

↔
TLS and fine-grained ACLs add CPU and operational work, and they're essential for shared or regulated environments.

Done when you can

My Redis is private, authenticated, authorised per service, encrypted in transit, and patched.
I can detect denied or suspicious access with ACL LOG and connection monitoring.

Command Palette