Learning Redis - Security: Authentication, ACL & Encryption

#Introduction

Redis is fast, but speed without security is a disaster. A Redis instance exposed to the internet without authentication is a favorite target — malicious scripts can FLUSHALL your data in an instant. Episode 14 covers layered defenses for Redis: authentication, ACL, TLS, and network hardening.

You'll learn from the simplest mechanism (requirepass) to granular per-user access control with ACL, then protect in-transit data with TLS, and close network holes via bind, protected-mode, and disabling dangerous commands.

#Basic Authentication: requirepass

#Single Password

The simplest way to protect Redis: one password for all connections, set via requirepass in redis.conf:

Set requirepass

redis-cli CONFIG SET requirepass "rahasia-kuat"
redis-cli -a "rahasia-kuat" PING

CONFIG SET requirepass "rahasia-kuat" enables the password. After that, every connection must authenticate — via -a in redis-cli, or AUTH in an interactive session. Without authentication, commands error with NOAUTH.

Danger

requirepass protects who can get in, but every user uses the same password — there's no separation of privileges. For multi-service environments, the ACL below is the right answer.

#Access Control Lists (ACL)

#Users with Permissions

Redis 6+ introduced ACL: you can define many users, each with its own password, key scope, and list of allowed commands. This replaces the one-password-for-everyone model.

Create a granular ACL user

redis-cli ACL SETUSER appuser on >secure_password ~app:* +@read +@write -@dangerous

redis-cli ACL SETUSER appuser on >secure_password ~app:* +@read +@write -@dangerous defines a user appuser who: is active (on), has the password secure_password (>), can only access keys matching the pattern app:* (~), is allowed the read and write command categories (+@read +@write), and is forbidden from using dangerous commands (-@dangerous).

#Viewing and Managing ACLs

List users and get an ACL

redis-cli ACL LIST
redis-cli ACL GETUSER appuser
redis-cli -u redis://appuser:secure_password@127.0.0.1:6379/0 GET app:1

ACL LIST shows all users and their rules. ACL GETUSER shows details for one user. The connection as appuser above can only run allowed commands on keys app:* — trying FLUSHALL or accessing key user:1 is rejected with a NOPERM error.

#Recommended User Patterns

User	Permissions	Purpose
`default`	Minimal (e.g. only `+ping`)	Fallback, admin via other mechanisms
`app`	`~app:* +@read +@write -@dangerous`	Application service
`worker`	`+@read +blpop +xreadgroup +xack`	Queue consumer
`admin`	`+@all`	Operations & debugging

Restrict users to the smallest role needed (least privilege). The default password should also be changed or disabled.

#In-Transit Encryption: TLS

#Enabling TLS

Data traveling over the network in the clear can be intercepted. Enable tls-port and provide certificates:

TLS configuration in redis.conf

tls-port 6380
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-port 6380 opens the encrypted port. Clients connect with --tls and verify certificates. Ideally also set tls-auth-clients yes for mutual TLS — server and client verify each other.

#Connecting Clients with TLS

redis-cli connection with TLS

redis-cli --tls -p 6380 \
  --cacert /etc/redis/tls/ca.crt \
  --cert /etc/redis/tls/redis-client.crt \
  --key /etc/redis/tls/redis-client.key

redis-cli --tls -p 6380 connects to the TLS port with the CA certificate and a client cert/key pair. In production, application libraries do the same with their respective TLS parameters.

#Network Security

#Limiting Exposure

Start with the most basic: never expose Redis to the internet.

Check bind and protected-mode

redis-cli CONFIG GET bind
redis-cli CONFIG GET protected-mode

CONFIG GET bind shows the interfaces Redis serves — set it to 127.0.0.1 for local-only access. protected-mode yes is on by default: Redis only accepts external connections if it has a password or binds to a public IP explicitly. The combination of bind 127.0.0.1 + protected-mode yes is the safest defensive position.

#Disabling Dangerous Commands

Destructive commands like FLUSHALL, FLUSHDB, and DEBUG don't need to be usable by applications. Disable them with rename-command:

Hardening commands in redis.conf

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command DEBUG ""
rename-command SHUTDOWN ""

rename-command FLUSHALL "" removes the command entirely (empty string = no alias). Operations teams that still need to run it can give it a hidden name, e.g. rename-command FLUSHALL "f5f5...", and keep it in a secret manager.

#Summary

Episode 14 equipped you with layered security: requirepass for basic authentication, ACL for granular user permissions, TLS for in-transit encryption, and hardening with bind, protected-mode, and rename-command.

Key takeaways:

requirepass protects access with a single password for all connections.
ACL (Redis 6+) creates users with their own password, key pattern, and command permissions.
ACL SETUSER appuser on >pass ~app:* +@read +@write -@dangerous is the basic pattern.
TLS (tls-port 6380) encrypts traffic; mutual TLS adds strength.
bind 127.0.0.1 + protected-mode yes minimizes network exposure.
rename-command FLUSHALL "" disables dangerous commands.
Never expose Redis directly to the internet without all of the layers above.

In the next episode, episode 15, we cover Redis Stack & Modules — RedisJSON for native JSON documents, RediSearch for full-text search, and RedisTimeSeries for time-series data. You'll see Redis transform from a key-value store into a multi-model database. Let's continue!