CacheInvalidation.org

Redis Security Boundaries for Multi-Tenant Applications

Multi-tenant Redis deployments fundamentally alter the threat model. The primary risk vector shifts from latency degradation to cross-tenant data leakage, unauthorized key mutation, and eviction-driven denial-of-service. Legacy single-tenant caching strategies—relying on requirepass and naive key prefixes—fail to enforce cryptographic or logical isolation at scale. Establishing rigid security boundaries requires treating tenant identifiers as first-class security principals, aligning isolation policies with the underlying Understanding Redis Cache Topology, and enforcing simultaneous network, ACL, and eviction segmentation.

flowchart LR
    T1[Tenant A client] -->|user tenant_a| ACL{Redis ACL}
    T2[Tenant B client] -->|user tenant_b| ACL
    ACL -->|key pattern ~tenant:a:*| KA[(Tenant A keyspace)]
    ACL -->|key pattern ~tenant:b:*| KB[(Tenant B keyspace)]
    ACL -. cross-tenant access denied .-> X[NOPERM]

Diagnostic Triage & Boundary Auditing

When cross-tenant access is suspected, immediate forensic triage must bypass application logs and query Redis directly. The ACL LOG command captures rejected commands, unauthorized user contexts, and key-space violations with millisecond precision.

# Retrieve recent ACL violations (default: 10 entries)
redis-cli ACL LOG

# Cross-reference with active connections to map offending IPs/service accounts
redis-cli CLIENT LIST | grep -E "addr=|user="

# Audit command execution frequency to detect bulk invalidation leaks
redis-cli INFO COMMANDSTATS | grep -E "cmdstat_KEYS|cmdstat_SCAN|cmdstat_DEL"

A poorly scoped SCAN or DEL during bulk invalidation can traverse tenant namespaces, triggering unauthorized cache misses or exposing stale references. Root-cause analysis of these boundary violations typically traces to three failure modes: permissive ACL inheritance, unbounded maxmemory eviction conflicts, and cluster slot migration without tenant-aware key pinning. Engineers must correlate ACL LOG timestamps with deployment windows to isolate configuration drift from application-level routing bugs.

Configuration Hardening & ACL Enforcement

Modern Redis (7.x+) deprecates rename-command in favor of granular ACLs. Tenant isolation requires explicit user scoping, command allowlisting, and key pattern enforcement. The following configuration demonstrates production-hardened ACL generation for a high-traffic tenant tier:

# Generate a random password (ACL GENPASS returns a password, not a hash)
redis-cli ACL GENPASS > tenant_123_pass

# A new ACL user starts with no commands and no key access, so we only grant
# what is permitted. Rules apply left-to-right; a trailing `resetpass` would
# wipe the password just set, and a late `-@write` would revoke earlier grants.
# Read across the tenant namespace; restrict writes to session keys via a
# selector (Redis 7.0+).
ACL SETUSER tenant_123 on ">$(cat tenant_123_pass)" \
  +@read ~tenant:123:* \
  (+@write ~tenant:123:session:*)

Critical Production Notes:

  • maxmemory-policy is instance-global in open-source Redis. You cannot assign tenant-specific eviction policies within a single instance. High-churn tenants must be routed to dedicated instances or Redis Enterprise databases to prevent eviction-driven cross-tenant cache stampedes.
  • Use ACL DRYRUN (Redis 7.2+) to validate tenant commands against policy before deployment: redis-cli ACL DRYRUN tenant_123 SET tenant:123:config:v2 "true"
  • Disable KEYS entirely via ACL. Replace with SCAN and enforce cursor-based pagination in application code to prevent blocking the event loop.

Python Client Implementation & Resilient Retry Patterns

In Python microservices, redis-py 5.x must be configured with strict tenant routing, connection validation, and deterministic retry logic. Dynamic ACL rule generation frequently outpaces connection pooling, causing NOAUTH or NOPERM exceptions during cold starts.

import redis
from redis.exceptions import AuthenticationError, NoPermissionError, ConnectionError
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
import logging

logger = logging.getLogger(__name__)

def get_tenant_client(tenant_id: str, password: str) -> redis.Redis:
    client = redis.Redis(
        host="cache.internal.svc",
        port=6379,
        username=f"tenant_{tenant_id}",
        password=password,
        decode_responses=True,
        socket_timeout=2.0,
        socket_connect_timeout=1.0,
        retry_on_timeout=True,
        health_check_interval=15
    )
    # Validate ACL context before returning
    whoami = client.acl_whoami()
    if whoami != f"tenant_{tenant_id}":
        raise RuntimeError(f"ACL mismatch: expected tenant_{tenant_id}, got {whoami}")
    return client

@retry(
    retry=retry_if_exception_type((AuthenticationError, NoPermissionError, ConnectionError)),
    wait=wait_exponential(multiplier=0.5, min=0.5, max=5),
    stop=stop_after_attempt(3),
    reraise=True
)
def tenant_cache_get(client: redis.Redis, key: str) -> str | None:
    try:
        return client.get(key)
    except NoPermissionError as e:
        logger.error(f"ACL boundary violation on key {key}: {e}")
        raise

Connection health checks must validate ACL WHOAMI before executing tenant-scoped operations. Implementing exponential backoff with jitter prevents thundering herds when ACL propagation lags behind connection pool initialization. For comprehensive connection handling, consult the official redis-py documentation.

CI/CD Gating & Policy Validation

Security boundaries degrade silently without automated validation. CI/CD pipelines must enforce ACL syntax validation, cross-tenant isolation testing, and dry-run execution before merging infrastructure changes.

# .github/workflows/redis-acl-gate.yml
name: Redis ACL Policy Validation
on:
  pull_request:
    paths: ['infra/redis/acl/*.acl']

jobs:
  validate-acl:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Start Redis 7.2
        run: docker run -d --name redis-test redis:7.2-alpine
      - name: Validate ACL Syntax
        run: |
          docker exec redis-test redis-cli ACL SETUSER test_user on >testpass ~tenant:* +@read
          docker exec redis-test redis-cli ACL DRYRUN test_user SET tenant:99:leak "blocked" | grep -q "OK" && exit 1
      - name: Cross-Tenant Isolation Test
        run: |
          python -m pytest tests/redis_isolation.py --redis-url=redis://localhost:6379

The pipeline must fail if any tenant user can access keys outside their ~tenant:<id>:* namespace. Integration tests should simulate concurrent tenant workloads, deliberately trigger SCAN operations, and assert zero cross-tenant key reads. Reference the official Redis ACL documentation for advanced rule composition and inheritance patterns.

Production Posture Checklist

Boundary enforcement is not a one-time configuration. It requires continuous validation, precise ACL scoping, and architectural alignment between cache topology and tenant routing. When invalidation cascades and eviction policies are mapped to explicit security principals, multi-tenant Redis transitions from a shared liability to a hardened, scalable asset.