Redis / Intermediate: application correctness and coordination / Lesson 12

Clients, ACLs, TLS and safe access

Separate connection discovery, authentication, authorization and transport protection. Use bounded clients and narrowly scoped key/command requirements without exposing credentials or administration.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain ACL users, command/key scope and TLS responsibilities.
Design pool, timeout and topology-aware client behavior.

Connection success is not operation authority

A TCP connection, a valid TLS session, authenticated user and allowed key command are separate checks. Redis ACLs were introduced in version 6 and can restrict users by supported command and key/channel permissions. A password alone is not transport encryption, and a key prefix alone is not authorization. Prefer a service identity with only its necessary operations rather than an administrator identity used for every request. Managed services can expose different control interfaces and restrictions, so provisioning belongs to an approved environment-specific process rather than a copied universal ACL snippet.

Write a requirement record without changing ACLs

The JSON describes a fictional cache-reader requirement, not executable Redis ACL configuration. It names a small command set, a tenant-specific key scope and required transport protection, while keeping credentials outside the record. The real owner must translate the requirement into supported ACL rules and test allowed and denied operations using the intended client. Script permissions, multi-key commands, channels and topology discovery can introduce additional requirements. Do not solve a permission error by allowing all commands or every key without evidence that such authority is necessary.

json Nonexecuting least-privilege requirement record

{
  "identity": "lab-cache-reader",
  "requiredCommands": ["GET", "MGET", "TTL"],
  "keyScope": ["lab:training-a:cache:*"],
  "transport": "validated-TLS",
  "credentials": "provided-by-approved-secret-system"
}

This metadata creates no user, secret, ACL or connection. It records a policy to implement and verify under the actual product.

Bound connections and protect stateful flows

Reuse clients or pools according to their documented concurrency model rather than opening an uncontrolled connection per request. Blocking list/stream consumers, subscriptions, WATCH and MULTI can need dedicated connection handling so unrelated requests do not inherit state. Set connect, command and application budgets from service needs and understand which timeout actually cancels work versus merely stops waiting. A larger pool does not increase Redis capacity automatically. Preserve error class and event identity when reconnecting so an uncertain successful write is not blindly resubmitted as a new non-idempotent event.

Test application scope without claiming a production authorizer

The local function permits only a declared tenant match and an allowed action. It illustrates two necessary inputs to a request decision and intentionally omits real identity proof, object ownership lookup and server ACL evaluation. A real application should derive the subject’s tenant from authenticated server-side context rather than trust a request-supplied tenant label. Use tests for cross-tenant and forbidden actions alongside valid reads. Constructing a permitted-looking Redis key is not sufficient evidence that the requester may use it, and Redis command access does not replace application business authorization.

python Offline application-scope model

def allowed_model(subject_tenant, record_tenant, action):
    return subject_tenant == record_tenant and action == 'read-cache'

assert allowed_model('training-a', 'training-a', 'read-cache')
assert not allowed_model('training-a', 'training-b', 'read-cache')
assert not allowed_model('training-a', 'training-a', 'admin')

Only the stated synthetic comparisons are tested. No identity provider, Redis ACL or live permission check is performed.

Match clients to topology and preserve secrets

Sentinel-aware and Cluster-aware clients discover different kinds of endpoint change; a plain fixed-host client may not handle either correctly. TLS certificate identity and trust must match every eligible endpoint, not only an initial connection seed. Store credentials through the approved secret mechanism and avoid command-line or diagnostic leakage. Protected mode is a guardrail, not a complete network, authentication and TLS design. Review supported server/client versions and managed command restrictions before deployment, and verify least privilege without changing any real service as part of a tutorial.

Common errors and fixes

NOAUTH Authentication required.

Why it happens: The operation reached a server that requires authentication.
How to fix it: Use the approved identity and credential flow, without exposing secrets.
Prevent it next time: Test client authentication and secret delivery before release.

NOPERM this user has no permissions

Why it happens: The authenticated identity lacks the needed supported operation or key scope.
How to fix it: Review the exact denied operation and narrow requirement with the owner.
Prevent it next time: Verify denied excess operations as well as permitted reads.

A timeout retry duplicates a write

Why it happens: Stopped waiting was treated as proof the server did nothing.
How to fix it: Reconcile event outcome and follow documented client retry rules.
Prevent it next time: Test lost replies and bounded reconnect behavior.

Check your understanding

1. A client can authenticate but receives NOPERM for a new key prefix. What should be reviewed?

Show worked solution

Inspect the exact command, key pattern and intended service requirement. Authentication succeeded, so blindly replacing credentials may not help. Have the authorized owner assess a narrow compatible permission change and test both the required access and denied unrelated prefixes. Do not grant global administrative authority just to remove the visible error.

2. Why should a blocking worker not casually share its connection with ordinary request traffic?