Chapter 22 · Security: ACLs, TLS, Command/Key Permissions, Secrets, and Network Boundaries

Default User, ACL Users, Passwords, Command Categories, Key Patterns, and Channel Patterns

Define Redis authentication and authorization precisely, then prove least privilege with named users, password hashes, command categories, directional key patterns, and Pub/Sub channel rules.

Advanced180–260 minutesACL users, key/channel patterns, DRYRUN, ACL LOGRedis Open Source 8.10.1Docker + redis-cli + OpenSSLStandalone ACL node + TLS primary/replicaDB 0 · AOF everysec + RDB · maxmemory 0/noevictionACL + mTLS + loopback/private networkFree/local-firstLast reviewed: September 6, 2026

Reproducible Chapter 22 baseline

Redis Open Source 8.10.1 using the pinned redis:8.10.1 image. Lessons 1–2 use a dedicated ACL-mechanics node published only to 127.0.0.1:6421. Lessons 3–5 use a separate TLS-only primary on host loopback 127.0.0.1:6422 plus one private-network replica on Docker network atlasmart-redis-ch22-net. Database 0; AOF everysec plus RDB save rule; maxmemory 0/noeviction; default ACL user disabled; disposable named ACL users; application key prefix atlasmart:ch22:*. Mutual TLS is enabled in the TLS lab, including the replication link. No Search/JSON/vector/time-series/probabilistic feature is required. All passwords and certificates shown are public lab-only material and must never be reused outside the disposable local lab.

Learning outcomes

This lesson turns Default User, ACL Users, Passwords, Command Categories, Key Patterns, and Channel Patterns into an observable AtlasMart workflow with explicit correctness, failure, and production boundaries.

Explain the mechanisms and terminology behind Default User, ACL Users, Passwords, Command Categories, Key Patterns, and Channel Patterns.

Collect Redis, client, configuration, and workload evidence before drawing operational conclusions.

Reproduce the lesson's deliberately incorrect or failure-prone case, diagnose the mechanism, and verify the repair.

Relate the design to memory, persistence, replication/Sentinel/Cluster, security, latency, and client behavior where applicable.

Apply the pattern to AtlasMart and state clearly what the implementation guarantees and what it does not guarantee.

1. Problem: one Redis credential silently became an administrator

AtlasMart started with one convenient password shared by the web API, background workers, dashboards, and operators. The application now only needs to read catalog keys, mutate cart/session keys, and publish a narrow notification channel—yet the shared identity can inspect configuration, alter ACLs, load modules, and touch every key. The first security job is therefore to separate authentication (who is this connection?) from authorization (what may that identity do?).

Transport Layer Security (TLS) and network isolation are separate layers. A successful AUTH proves a credential to Redis; it does not encrypt bytes on the wire, authorize an end customer, or make an internet-exposed Redis safe.

2. Default user and named ACL users

Redis Access Control Lists (ACLs) are available in Redis Open Source 6.0+. The built-in default user exists for compatibility and is commonly broad in an untouched deployment. This chapter disables it and uses named identities. A new ACL user starts with no useful privileges unless rules are added. reset is the safest starting point when defining a user from scratch because ACL SETUSER otherwise applies rules incrementally.

Concept	Meaning	Security consequence
`on`/`off`	Whether the ACL user can authenticate	Use `off` to revoke new authentication while investigating.
Password rules	One or more password hashes/credentials	Multiple passwords permit staged rotation; treat all client secrets as credentials.
Command rules	Individual commands or `@category` groups	Prefer explicit needs/categories over `+@all`.
Key patterns	`~`, `%R~`, `%W~`, `%RW~`	Redis 7+ can separate read and write key authorization.
Channel patterns	`&pattern`	Pub/Sub channels have their own authorization namespace.

3. Build a disposable ACL file with hashed passwords

The public course needs copyable credentials, but the Redis ACL file does not need to contain their cleartext. Redis ACL syntax accepts #<sha256> password hashes. The following public lab passwords are intentionally disposable; do not reuse them. The application receives read-only catalog access, read/write cart/session access, and one Pub/Sub channel namespace. It receives neither @admin nor @dangerous.

users.acl · hashed disposable identities

user default offuser academy-admin on #cf54dd75279c684b6ee7a545a4cdc06ff4de71cbcfe57c6fb79dc3ef9f519d2f ~* &* +@alluser atlasmart-app on #a753450b5a9cc3f06436e022127d46e54a44ba7d356801bc72887a7c4d261554 resetkeys resetchannels %R~atlasmart:ch22:catalog:* %RW~atlasmart:ch22:cart:* %RW~atlasmart:ch22:session:* &atlasmart:ch22:notify:* +@read +@write +@connection +publish +subscribe -@admin -@dangeroususer atlasmart-monitor on #39b516955abcb57911c7236f2f54a12b0753ab3a776f9fc4ea88f262c04f4b08 resetkeys resetchannels +ping +info +acl|whoamiuser atlasmart-operator on #1b35d0bc3717931259832eabf2e9503100d870c8563756661ef47137dc891c81 resetkeys resetchannels +ping +info +client|list +client|id +config|get +slowlog|get +slowlog|len +latency|latest +latency|history +acl|whoami +acl|getuser +acl|dryrunuser replica-sync on #085c4362e485e79749f7ac44f6fac58acfe607187fa4c58c6e9cea407a9a7b0d resetkeys resetchannels +psync +replconf +ping

4. Verify that the hashes match the documented lab passwords

Hashing the password is not encryption and does not make a weak password safe. This portable Python check simply proves the training file and the documented cleartext credentials correspond. Production credentials should be randomly generated, high entropy, delivered from a secrets system, and never committed in source.

Python · reproduce SHA-256 hashes without external packages

import hashlibsecrets = {    "academy-admin": "AtlasMart-Ch22-Admin-Lab-Only-2026",    "atlasmart-app": "AtlasMart-Ch22-App-Lab-Only-2026",    "atlasmart-monitor": "AtlasMart-Ch22-Monitor-Lab-Only-2026",    "atlasmart-operator": "AtlasMart-Ch22-Operator-Lab-Only-2026",    "replica-sync": "AtlasMart-Ch22-Repl-Lab-Only-2026",}for name, secret in secrets.items():    print(name, hashlib.sha256(secret.encode("utf-8")).hexdigest())

5. Start the ACL-mechanics node on loopback only

This first node is intentionally not TLS-enabled so Lesson 1 can keep identity/authorization mechanics separate from transport encryption. Its only published host endpoint is 127.0.0.1:6421; it is not a production design. The default user is off, persistence is explicit, and startup hardening leaves protected CONFIG/DEBUG/MODULE capabilities disabled.

Shell · start the dedicated ACL node

docker run -d --name atlasmart-redis-ch22-acl \  -p 127.0.0.1:6421:6379 \  -v "$PWD/users.acl:/usr/local/etc/redis/users.acl:rw" \  -v atlasmart-redis-ch22-acl-data:/data \  redis:8.10.1 redis-server \  --bind 0.0.0.0 --protected-mode yes \  --aclfile /data/users.acl \  --appendonly yes --appendfsync everysec --save 300 10 \  --enable-protected-configs no --enable-debug-command no --enable-module-command no

6. Prove identity and inspect effective policy

Use an administrator only to inspect ACL state. ACL WHOAMI proves the current connection identity. ACL LIST shows effective rules, while ACL GETUSER exposes structured flags, password hashes, command rules, key patterns, channel patterns, and selectors. RESP2/RESP3 presentation can differ, but effective permission should not.

Shell · identity and effective rules

docker exec -e REDISCLI_AUTH=AtlasMart-Ch22-Admin-Lab-Only-2026 atlasmart-redis-ch22-acl redis-cli --user academy-admin ACL WHOAMIdocker exec -e REDISCLI_AUTH=AtlasMart-Ch22-Admin-Lab-Only-2026 atlasmart-redis-ch22-acl redis-cli --user academy-admin ACL GETUSER atlasmart-appdocker exec -e REDISCLI_AUTH=AtlasMart-Ch22-Admin-Lab-Only-2026 atlasmart-redis-ch22-acl redis-cli --user academy-admin ACL CAT admindocker port atlasmart-redis-ch22-acl 6379

7. ACL DRYRUN: prove command, key, and channel boundaries without side effects

ACL DRYRUN (Redis 7+) asks Redis whether a user could execute a concrete command but does not execute it. This is especially useful for dangerous commands or a CI policy test. These checks should return a mix of OK and descriptive ACL denials. Notice that write permission on cart keys does not imply write permission on catalog keys, and channel authorization is checked separately.

Shell · least-privilege contract tests

A="docker exec -e REDISCLI_AUTH=AtlasMart-Ch22-Admin-Lab-Only-2026 atlasmart-redis-ch22-acl redis-cli --user academy-admin"$A ACL DRYRUN atlasmart-app GET atlasmart:ch22:catalog:sku42$A ACL DRYRUN atlasmart-app SET atlasmart:ch22:catalog:sku42 changed$A ACL DRYRUN atlasmart-app SET atlasmart:ch22:cart:c42 '{"items":1}'$A ACL DRYRUN atlasmart-app GET unrelated:key$A ACL DRYRUN atlasmart-app PUBLISH atlasmart:ch22:notify:orders changed$A ACL DRYRUN atlasmart-app PUBLISH private:admin changed$A ACL DRYRUN atlasmart-app CONFIG GET maxmemory

8. Actual application proof and an intentional denial

Now execute a small positive/negative fixture rather than trusting policy text. The administrator seeds one catalog key. The application may read it and mutate its own cart key, but the application write to the catalog must fail. A failed authorization proves the ACL boundary; it does not prove data-level business authorization for individual AtlasMart customers.

Shell · observable allow/deny behavior

docker exec -e REDISCLI_AUTH=AtlasMart-Ch22-Admin-Lab-Only-2026 atlasmart-redis-ch22-acl redis-cli --user academy-admin SET atlasmart:ch22:catalog:sku42 '{"price":1999}'docker exec -e REDISCLI_AUTH=AtlasMart-Ch22-App-Lab-Only-2026 atlasmart-redis-ch22-acl redis-cli --user atlasmart-app GET atlasmart:ch22:catalog:sku42docker exec -e REDISCLI_AUTH=AtlasMart-Ch22-App-Lab-Only-2026 atlasmart-redis-ch22-acl redis-cli --user atlasmart-app SET atlasmart:ch22:cart:c42 '{"items":1}'docker exec -e REDISCLI_AUTH=AtlasMart-Ch22-App-Lab-Only-2026 atlasmart-redis-ch22-acl redis-cli --user atlasmart-app SET atlasmart:ch22:catalog:sku42 forbidden

9. Authentication failure evidence is not a full audit trail

Submit one intentionally wrong disposable password, then inspect ACL LOG. Redis records recent ACL authentication/authorization failures with contextual client information. It is useful incident evidence but is bounded in-memory diagnostic state, not a durable compliance/SIEM audit system.

Shell · controlled AUTH failure and ACL LOG

docker exec -e REDISCLI_AUTH=wrong-ch22-password atlasmart-redis-ch22-acl redis-cli --user atlasmart-app PING || truedocker exec -e REDISCLI_AUTH=AtlasMart-Ch22-Admin-Lab-Only-2026 atlasmart-redis-ch22-acl redis-cli --user academy-admin ACL LOG 10

10. Deliberately wrong: “application +@all is simplest”

+@all ~* &* collapses every Redis control plane into the application identity and can also include module commands. Removing a few famous commands from an additive +@all rule is fragile as server/module command surfaces evolve. Repair from reset, grant only needed categories/commands, restrict key direction/prefix and channels, then make ACL DRYRUN contract tests part of deployment validation.

11. Production judgment

ACLs are appropriate for Redis connection identities and Redis resource/command boundaries. They do not replace application authorization such as “customer 42 may update cart 42,” encryption, network segmentation, host/container hardening, or secret rotation. Track ACL denials, authentication failures, privileged identities, ACL-file changes, and unexpected clients. Review command-category expansion when upgrading Redis or adding modules. Next, map least privilege to application, operator, monitoring, replication, Sentinel, and Cluster roles.

Check your understanding

Does AUTH encrypt the password or subsequent commands on the network?
Why use reset when defining an ACL user?
What is the difference between %R~ and %RW~?
Does an ACL key pattern implement customer-level business authorization?

Review the answers

No. AUTH authenticates a connection. Use TLS for transport confidentiality/integrity.

ACL SETUSER is incremental for an existing user; reset gives a known empty baseline before new rules are applied.

%R~ grants read access to matching keys, while %RW~ grants both read and write access. Command permission is still required separately.

No. Redis ACL patterns constrain Redis identities. The application must still enforce its own tenant/customer authorization.

Summary and next step

Default User, ACL Users, Passwords, Command Categories, Key Patterns, and Channel Patterns is now connected to observable Redis behavior, bounded failure cases, and production tradeoffs. Keep the evidence and cleanup state from this lesson; next, continue with Least Privilege for Applications, Operators, Monitoring, Replication, Sentinel, and Cluster.

Authoritative references

Keep knowledge open

Help the academy stay free and grow.

If these tutorials save you time, a small donation supports new lessons, technical review, diagrams, examples, and long-term maintenance.

ETHEthereum / ERC-20 only

0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0

Send only Ethereum or ERC-20 compatible assets to this address.