Redis Authentication Done Right: ACL Users, Least Privilege, TLS, and Rotation

Redis Authentication Done Right: ACL Users, Least Privilege, TLS, and Rotation

Redis authentication is not the same thing as authenticating users in your application. It protects connections to Redis itself: which service may connect, which commands it may run, which keys or channels it may touch, and how that access is revoked.

For modern Redis deployments, the right baseline is usually named ACL users + least-privilege permissions + TLS + network isolation. A single global password can still work for simple deployments, but it gives every authenticated client the same authority.

The security model: four layers, not one password

A production Redis connection should pass through several controls:

1. Network boundary — Redis should not be casually reachable from the public internet.
2. Transport security — TLS protects credentials and data from network eavesdropping.
3. Authentication — Redis identifies the connecting client, normally with a named ACL user.
4. Authorization — ACL rules decide which commands, keys, and Pub/Sub channels that user can access.

Authentication alone is not a substitute for the other layers. Redis documentation explicitly notes that AUTH is just a Redis command; without encrypted transport, credentials can be observed by an attacker who can inspect the network.

Prefer Redis ACLs over a shared requirepass

Redis 6 introduced Access Control Lists. ACLs let you create named users and restrict each one independently. Redis documents ACLs as the recommended authentication method for modern deployments.

The legacy configuration is requirepass:

requirepass a-very-long-random-secret

Clients then authenticate with:

AUTH a-very-long-random-secret

This is simple, but every client sharing that credential effectively becomes the same Redis identity.

With ACLs, authentication becomes:

AUTH app-worker strong-random-password

That connection is now associated with app-worker, and Redis can enforce permissions specifically for that user.

Why named users matter

Named ACL users make it possible to separate workloads such as:

• an API service that only reads and writes session:*
• a background worker that operates on jobs:*
• an analytics process that should be read-only
• an administrator that needs operational commands

If one credential leaks, the blast radius is bounded by that user's permissions instead of exposing every key and command available to the Redis server.

Build users from least privilege

A useful ACL should answer three questions:

• Which commands may this service execute?
• Which keys may it access?
• Which Pub/Sub channels may it use?

For example, the authorization portion for a small service that only needs basic operations on keys under app: can be built deliberately:

ACL SETUSER app-service reset on ~app:* +GET +SET +DEL +EXPIRE +TTL

Then attach a strong credential using your supported Redis or managed-provider credential workflow. The important idea is the shape of the policy:

• reset clears previous rules before rebuilding the user
• on enables the user
• ~app:* limits accessible keys
• explicit +COMMAND rules grant only the commands the service actually needs

For a broader policy, Redis also supports command categories such as +@read, but categories should still be reviewed carefully. A broad category is convenient; an explicit command set is easier to reason about for tightly scoped services.

Avoid starting with +@all ~* for every application user. That removes most of the security value ACLs are meant to provide.

The default user deserves attention

A default Redis ACL configuration is intentionally backward compatible. The special default user may be enabled with nopass and broad access unless you change the configuration.

After creating dedicated users, production environments commonly restrict or disable unauthenticated default access rather than leaving it as the path every application uses.

Before making that change, verify that:

• every legitimate client supports username/password authentication
• health checks use an intended Redis identity
• Sentinel, replication, administration, and monitoring paths have the permissions they require
• connection pools can reconnect cleanly with the new credentials

Security changes that are correct on paper can still cause an outage when an overlooked client depends on the old identity.

Use TLS when credentials cross an untrusted network

AUTH authenticates a connection; it does not encrypt the connection.

Redis Open Source supports TLS for client connections and can also use TLS for replication and Redis Cluster communication when configured appropriately. Managed Redis products may expose TLS through their own control plane.

At minimum, use TLS whenever traffic crosses networks you do not fully trust. Publicly reachable Redis endpoints should be avoided in the first place; network controls and private connectivity are stronger first-line protections than relying on a password alone.

Generate strong credentials

Redis is extremely fast at processing commands, so weak passwords are a poor defense against guessing attacks. Redis provides ACL GENPASS in Redis Open Source to generate high-entropy credentials:

ACL GENPASS

Treat generated credentials like any other infrastructure secret:

• keep them in a secret manager rather than source control
• do not bake them into container images
• do not print them in application logs
• avoid sharing one credential between unrelated services
• rotate them when exposure is suspected or when your security policy requires it

Managed Redis products can differ in how ACL users and credentials are administered, so follow the provider's supported control-plane workflow rather than assuming every Open Source ACL management command is available.

Rotate credentials without a hard cutover

Redis ACL users can have multiple passwords. That enables a safer rotation pattern than replacing a single secret and hoping every process switches instantly.

A typical rollout is:

1. Add the new credential to the existing ACL user.
2. Update application secret stores.
3. Roll or reconnect clients so new connections use the new credential.
4. Confirm traffic is healthy.
5. Remove the old credential.
6. If immediate revocation is required, terminate connections authenticated as that user so stale connections cannot continue using an already authenticated session.

This matters because changing or disabling an ACL user does not always retroactively transform every established connection in the way teams intuitively expect. Redis provides user-aware client management such as CLIENT KILL USER app-service when existing connections must be terminated deliberately.

Test ACLs before production traffic depends on them

Redis 7 introduced ACL DRYRUN, which can test whether a user would be allowed to execute a command without performing the command itself.

ACL DRYRUN app-service GET app:user:42
ACL DRYRUN app-service CONFIG GET '*'

A useful test suite should prove both sides of the policy:

• commands that must succeed are allowed
• commands that must not succeed are denied
• allowed commands cannot escape the intended key namespace
• Pub/Sub access is restricted when channels are used

Testing only the happy path is not enough. A least-privilege policy is valuable precisely because forbidden operations stay forbidden.

Watch the ACL security log

Redis Open Source provides ACL LOG for recent ACL-related security events, including:

• failed authentication attempts
• commands rejected by policy
• denied key access
• denied Pub/Sub channel access

ACL LOG 10

This is useful during rollouts and incident investigation. A sudden increase in failed AUTH attempts might mean a bad deployment, stale credentials, or malicious probing. Repeated command denials might reveal that an application's real command usage differs from the policy you designed.

Do not rely on the Redis ACL log as your entire security-monitoring system. Infrastructure logs, network telemetry, secret-manager audit trails, and managed-service events should complement it.

Common authentication mistakes

1. Treating Redis auth as application auth

Redis ACL users should usually represent trusted services or infrastructure identities, not every end user of your product. Your application should authenticate its own users, then access Redis through a controlled backend identity.

2. Giving every service admin-level access

If an application only needs GET, SET, and EXPIRE on one key prefix, it should not also be able to run administrative or destructive commands.

3. Sharing one password everywhere

A shared credential makes attribution, rotation, and blast-radius control much harder.

4. Using AUTH without TLS on exposed networks

Authentication proves knowledge of a secret; it does not encrypt the secret in transit.

5. Rotating a password without planning for existing connections

Connection pools may remain authenticated for a long time. Decide whether old connections can drain naturally or need explicit termination.

6. Assuming managed Redis behaves exactly like Redis Open Source

Redis Cloud and Redis Software expose access control through product-specific workflows and do not support every ACL-management command in the same way as a standalone Redis Open Source server.

A practical production baseline

For most backend deployments, a strong default is:

• keep Redis on a private network or tightly controlled endpoint
• enable TLS when traffic can cross an untrusted network
• create one named ACL identity per service or trust boundary
• disable unnecessary default access
• grant only the commands and key/channel patterns required
• store credentials in a secret manager
• test policies with ACL DRYRUN where supported
• monitor authentication and ACL failures
• rotate credentials with an explicit reconnection/revocation plan

Redis authentication works best when it is treated as service identity plus authorization, not as a checkbox labeled "password enabled."

Official references

• Redis security documentation
• Redis ACL documentation
• AUTH command
• ACL DRYRUN command
• ACL LOG command