07.05.Redis Scalability Security

07.05. Redis Scalability Security

1. Executive Summary

The current Redis implementation provides a solid foundation for session management and transient state. However, it faces critical risks in high-load scenarios and production environments due to single-instance infrastructure, lack of transit security, and rudimentary connection handling.

2. Infrastructure Analysis (GCP Memorystore)

2.1 Weakness: BASIC Tier (No High Availability)

Current Status: Provisioned as tier = "BASIC" in Terraform.
Risk: A single zone failure or Redis process crash will result in total loss of all active user sessions and pending payments. This is a fatal blocker for "World-Class" robustness.
Scalability: Basic tier does not support read replicas, meaning all load (read/write) hits a single CPU.

2.2 Weakness: Lack of Transit Encryption (TLS)

Current Status: TLS is not enabled in the google_redis_instance resource.
Risk: Data transmitted between Cloud Run and Redis (including encrypted tokens and session metadata) travels in plain text within the VPC. While internal, it violates zero-trust security principles.

2.3 Weakness: Authentication (Auth String)

Current Status: auth_enabled is not set in Terraform.
Risk: Any service within the same authorized network can read/write to Redis without a password.

3. End-to-End (E2E) Application Analysis

3.1 Robustness: Connection Pooling & Retries

Current Status: RedisClient uses redis.from_url without explicit connection pool tuning or retry strategies.
Risk: Under heavy concurrent load (e.g., thousands of simultaneous Tesla owners), the client may exhaust available connections or fail abruptly during transient network blips between Cloud Run and Redis.

3.2 Security: Application-Level Encryption

Current Status: STRENGTH. TeslaFleetService correctly uses Fernet (AES-256) to encrypt tokens before saving to Redis.
Weakness: The encryption key is shared via settings.TOKEN_ENCRYPTION_KEY. If this key is not rotated, a historic dump of Redis could eventually be decrypted if the key is ever leaked.

3.3 Scalability: Memory Management (TTL)

Current Status: Uses a 30-minute hard TTL with a 2-hour "Sliding TTL" in E2E mode.
Risk: In a global surge, 1GB of memory could be exhausted if sessions are not pruned correctly. Redis is currently configured with volatile-lru (default) which is safe, but memory pressure could lead to premature session eviction.

4. Concrete Specifications for Fixes

4.1 Infrastructure (Terraform) - Step 027

Spec: Upgrade to Standard HA and Enable Security 1. Upgrade Tier: Change tier from BASIC to STANDARD_HA. 2. Enable Auth: Set auth_enabled = true and retrieve the auth_string via a data source or output to store in Secret Manager. 3. Enable TLS: Set transit_encryption_mode = "SERVER_AUTHENTICATION".

4.2 Application (Python) - `app/core/redis.py`

Spec: Robust Connection Management 1. Tuned Connection Pool:

self._client = redis.from_url(
    settings.REDIS_URL,
    decode_responses=True,
    max_connections=20, # Adjust based on Cloud Run concurrency
    socket_timeout=5.0,
    socket_keepalive=True,
    retry_on_timeout=True
)

TLS Support: Update REDIS_URL to rediss:// (note the double 's') and configure SSL context to trust GCP's CA.

4.3 Security - Key Rotation

Spec: Envelope Encryption 1. Move from a static TOKEN_ENCRYPTION_KEY to GCP KMS (Key Management Service). 2. Use the Service Account identity to "Wrap/Unwrap" session keys, ensuring the actual master key never leaves GCP's Hardware Security Modules (HSM).

4.4 Monitoring

Spec: Redis Health Dashboard 1. Add alerting for redis.googleapis.com/stats/memory/usage_ratio > 0.8. 2. Monitor redis.googleapis.com/network/instanteous_ops_per_sec to detect thundering herd issues during surges.