Security
Architecture

// HS256 (HMAC-SHA256) — SYMMETRIC
// Same key used to sign AND verify.
// Problem: every service that verifies must have the secret key.
// If any service is compromised → attacker can forge any token.
token = jwt.sign(payload, "shared-secret-key", { algorithm: "HS256" })
jwt.verify(token, "shared-secret-key")   ← every service needs this key

// RS256 (RSA-SHA256) — ASYMMETRIC ← PREFERRED
// Auth server signs with PRIVATE key (kept secret, only auth server has it).
// All services verify with PUBLIC key (published at JWKS endpoint).
// Compromise of any service → cannot forge tokens (no private key).
token = jwt.sign(payload, private_key, { algorithm: "RS256", keyid: "key-1" })
public_key = fetch("https://auth.co.com/.well-known/jwks.json")
jwt.verify(token, public_key, {
  algorithms: ["RS256"],     ← whitelist ONLY RS256
  audience: "api.co.com",   ← verify aud claim
  issuer: "auth.co.com"    ← verify iss claim
})

// Regular TLS: only CLIENT verifies server certificate.
// mTLS: BOTH sides verify each other. Used for service-to-service auth.

Client (order-service)            Server (payment-service)
    |                                    |
    |--- ClientHello ------------------>|
    |<-- ServerHello + ServerCert ------|  ← server sends its cert
    |    (CN=payment-service,           |
    |     issued by internal-CA)        |
    |                                   |
    |--- ClientCert ------------------->|  ← client sends its cert
    |    (CN=order-service,             |
    |     issued by internal-CA)        |
    |                                   |
    // Both sides verify:
    // 1. Certificate signed by trusted internal CA?
    // 2. Certificate not expired?
    // 3. Certificate not in CRL (revoked)?
    // 4. Subject (CN) matches expected service name?
    |                                   |
    |=== Encrypted channel established ==|
    |--- GET /charge (HTTP/1.1) ------->|  ← now authorized

// Service mesh (Istio) automates all of this:
// Envoy sidecar handles mTLS transparently.
// Policy: "order-service → payment-service: ALLOW"
//         "frontend → payment-service: DENY"
// Your application code calls http://payment-service/charge
// Envoy sidecar upgrades to mTLS automatically.

// Cert rotation (SPIRE):
// SPIRE issues short-lived SVIDs (24–72 hrs) to every workload.
// Automatic rotation before expiry — zero manual cert management.

// Flat network (DEFAULT, DANGEROUS):
// Any pod can call any pod. Compromised frontend → calls payment DB directly.

// Microsegmented (ZERO-TRUST):
// All traffic denied by default. Explicit allows only.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payment-service-policy
spec:
  podSelector:
    matchLabels: { app: payment-service }
  policyTypes: [Ingress, Egress]
  ingress:
  - from:
    - podSelector:
        matchLabels: { app: order-service }  ← ONLY order-service may call payment
    ports: [{ port: 8080 }]
  egress:
  - to:
    - podSelector:
        matchLabels: { app: payment-db }     ← ONLY payment-db may be called

// Blast radius comparison:
// Without Zero-Trust: compromised transcoding pod → access to payment DB, user DB, secrets
// With Zero-Trust: compromised transcoding pod → can only reach video-storage S3 bucket
//                  (its only explicit allow). Attacker is contained.

// STATIC secret (dangerous): long-lived DB password stored as a secret
// If the secret leaks: valid forever until manually rotated.

// DYNAMIC secret (Vault): Vault generates credentials per-request, with TTL

// App startup: request DB credentials from Vault
response = vault.read("database/creds/my-role")
// Vault generates: { username: "v-app-20250307-abc", password: "xyz", lease_ttl: "1h" }
// Vault creates this user in the DB with read permissions
// After 1 hour: Vault AUTOMATICALLY revokes the DB user

db.connect(
  host="db.internal",
  user=response.username,     ← temporary, unique to this app instance
  password=response.password  ← expires in 1 hour
)

// App renews lease before expiry:
vault.renew(response.lease_id)  ← extend by another hour

// Benefits:
// • No long-lived credentials → breach window is at most 1 hour
// • Full audit log: who requested what credential, when
// • Automatic cleanup: no orphaned credentials accumulate
// • Unique per instance: compromise of one pod ≠ compromise of all pods

// BRUTE FORCE on login endpoint:
// Without protection: attacker tries 10M passwords/second.
def check_login_rate_limit(ip, user_id):
    # Per-IP: 5 attempts per 15 minutes (stops distributed single-user attack)
    ip_key = f"login:ip:{ip}"
    ip_count = redis.incr(ip_key)
    if ip_count == 1: redis.expire(ip_key, 900)   # 15 min window
    if ip_count > 5: raise TooManyRequests

    # Per-user: 10 attempts per hour (stops distributed multi-IP attack)
    user_key = f"login:user:{user_id}"
    user_count = redis.incr(user_key)
    if user_count == 1: redis.expire(user_key, 3600)  # 1 hour window
    if user_count > 10:
        send_suspicious_activity_alert(user_id)
        raise TooManyRequests

// CREDENTIAL STUFFING (breached credentials list from other sites):
// Attacker uses many different IPs → per-IP limits ineffective.
// Fix: rate limit per user_id (not just IP). CAPTCHA after 3 failures.
// HIBP (Have I Been Pwned) check: reject passwords in known breach datasets.
// Device fingerprinting: flag new device + failed login → MFA challenge.

// DDoS mitigation layers:
// L3/4 volumetric (millions of packets): ISP BGP blackholing, AWS Shield Standard
// L7 application (HTTP flood): Cloudflare WAF, AWS WAF, rate limiting, CAPTCHA
// Anycast: Cloudflare has 200+ PoPs — attack absorbed at edge, never reaches origin