bakery-ia/docs/06-security/tls-configuration.md

TLS/SSL Configuration Guide

Last Updated: November 2025 Status: Production Ready Protocol: TLS 1.2+

---

Table of Contents

1. Overview
2. Certificate Infrastructure
3. PostgreSQL TLS Configuration
4. Redis TLS Configuration
5. Client Configuration
6. Deployment
7. Verification
8. Troubleshooting
9. Maintenance
10. Related Documentation

---

Overview

This guide provides detailed information about TLS/SSL implementation for all database and cache connections in the Bakery IA platform.

What's Encrypted

• ✅ 14 PostgreSQL databases with TLS 1.2+ encryption
• ✅ 1 Redis cache with TLS encryption
• ✅ All microservice connections to databases
• ✅ Self-signed CA with 10-year validity
• ✅ Certificate management via Kubernetes Secrets

Security Benefits

• Confidentiality: All data in transit is encrypted
• Integrity: TLS prevents man-in-the-middle attacks
• Compliance: Meets PCI-DSS, GDPR, and SOC 2 requirements
• Performance: Minimal overhead (<5% CPU) with significant security gains

Performance Impact

Metric	Before	After	Change
Connection Latency	~5ms	~8-10ms	+60% (acceptable)
Query Performance	Baseline	Same	No change
Network Throughput	Baseline	-10% to -15%	TLS overhead
CPU Usage	Baseline	+2-5%	Encryption cost

---

Certificate Infrastructure

Certificate Hierarchy

Root CA (10-year validity)
├── PostgreSQL Server Certificates (3-year validity)
│   └── Valid for: *.bakery-ia.svc.cluster.local
└── Redis Server Certificate (3-year validity)
    └── Valid for: redis-service.bakery-ia.svc.cluster.local

Certificate Details

Root CA:

• Algorithm: RSA 4096-bit
• Signature: SHA-256
• Validity: 10 years (expires 2035)
• Common Name: Bakery IA Internal CA

Server Certificates:

• Algorithm: RSA 4096-bit
• Signature: SHA-256
• Validity: 3 years (expires October 2028)
• Subject Alternative Names:
  • PostgreSQL: *.bakery-ia.svc.cluster.local, localhost
  • Redis: redis-service.bakery-ia.svc.cluster.local, localhost

Certificate Files

infrastructure/tls/
├── ca/
│   ├── ca-cert.pem          # CA certificate (public)
│   └── ca-key.pem           # CA private key (KEEP SECURE!)
├── postgres/
│   ├── server-cert.pem      # PostgreSQL server certificate
│   ├── server-key.pem       # PostgreSQL private key
│   ├── ca-cert.pem          # CA for client validation
│   └── san.cnf              # Subject Alternative Names config
├── redis/
│   ├── redis-cert.pem       # Redis server certificate
│   ├── redis-key.pem        # Redis private key
│   ├── ca-cert.pem          # CA for client validation
│   └── san.cnf              # Subject Alternative Names config
└── generate-certificates.sh  # Regeneration script

Generating Certificates

To regenerate certificates (e.g., before expiry):

cd infrastructure/tls
./generate-certificates.sh

This script:

1. Creates a new Certificate Authority (CA)
2. Generates server certificates for PostgreSQL
3. Generates server certificates for Redis
4. Signs all certificates with the CA
5. Outputs certificates in PEM format

---

PostgreSQL TLS Configuration

Server Configuration

PostgreSQL requires specific configuration to enable TLS:

postgresql.conf:

# Network Configuration
listen_addresses = '*'
port = 5432

# SSL/TLS Configuration
ssl = on
ssl_cert_file = '/tls/server-cert.pem'
ssl_key_file = '/tls/server-key.pem'
ssl_ca_file = '/tls/ca-cert.pem'
ssl_prefer_server_ciphers = on
ssl_min_protocol_version = 'TLSv1.2'

# Cipher suites (secure defaults)
ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL'

Kubernetes Deployment Configuration

All 14 PostgreSQL deployments use this structure:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth-db
  namespace: bakery-ia
spec:
  template:
    spec:
      securityContext:
        fsGroup: 70  # postgres group

      # Init container to fix certificate permissions
      initContainers:
      - name: fix-tls-permissions
        image: busybox:latest
        securityContext:
          runAsUser: 0  # Run as root to chown files
        command: ['sh', '-c']
        args:
        - |
          cp /tls-source/* /tls/
          chmod 600 /tls/server-key.pem
          chmod 644 /tls/server-cert.pem /tls/ca-cert.pem
          chown 70:70 /tls/*
        volumeMounts:
        - name: tls-certs-source
          mountPath: /tls-source
          readOnly: true
        - name: tls-certs-writable
          mountPath: /tls

      # PostgreSQL container
      containers:
      - name: postgres
        image: postgres:17-alpine
        command:
        - docker-entrypoint.sh
        - -c
        - config_file=/etc/postgresql/postgresql.conf
        volumeMounts:
        - name: tls-certs-writable
          mountPath: /tls
        - name: postgres-config
          mountPath: /etc/postgresql
        - name: postgres-data
          mountPath: /var/lib/postgresql/data

      volumes:
      # TLS certificates from Kubernetes Secret (read-only)
      - name: tls-certs-source
        secret:
          secretName: postgres-tls
      # Writable TLS directory (emptyDir)
      - name: tls-certs-writable
        emptyDir: {}
      # PostgreSQL configuration
      - name: postgres-config
        configMap:
          name: postgres-logging-config
      # Data persistence
      - name: postgres-data
        persistentVolumeClaim:
          claimName: auth-db-pvc

Why Init Container?

PostgreSQL has strict requirements:

1. Permission Check: Private key must have 0600 permissions
2. Ownership Check: Files must be owned by postgres user (UID 70)
3. Kubernetes Limitation: Secret mounts are read-only with fixed permissions

Solution: Init container copies certificates to emptyDir with correct permissions.

Kubernetes Secret

apiVersion: v1
kind: Secret
metadata:
  name: postgres-tls
  namespace: bakery-ia
type: Opaque
data:
  server-cert.pem: <base64-encoded-certificate>
  server-key.pem: <base64-encoded-private-key>
  ca-cert.pem: <base64-encoded-ca-certificate>

Create from files:

kubectl create secret generic postgres-tls \
  --from-file=server-cert.pem=infrastructure/tls/postgres/server-cert.pem \
  --from-file=server-key.pem=infrastructure/tls/postgres/server-key.pem \
  --from-file=ca-cert.pem=infrastructure/tls/postgres/ca-cert.pem \
  -n bakery-ia

---

Redis TLS Configuration

Server Configuration

Redis TLS is configured via command-line arguments:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  namespace: bakery-ia
spec:
  template:
    spec:
      containers:
      - name: redis
        image: redis:7-alpine
        command:
        - redis-server
        - --requirepass
        - $(REDIS_PASSWORD)
        - --tls-port
        - "6379"
        - --port
        - "0"  # Disable non-TLS port
        - --tls-cert-file
        - /tls/redis-cert.pem
        - --tls-key-file
        - /tls/redis-key.pem
        - --tls-ca-cert-file
        - /tls/ca-cert.pem
        - --tls-auth-clients
        - "no"  # Don't require client certificates
        env:
        - name: REDIS_PASSWORD
          valueFrom:
            secretKeyRef:
              name: bakery-ia-secrets
              key: REDIS_PASSWORD
        volumeMounts:
        - name: tls-certs
          mountPath: /tls
          readOnly: true
        - name: redis-data
          mountPath: /data
      volumes:
      - name: tls-certs
        secret:
          secretName: redis-tls
      - name: redis-data
        persistentVolumeClaim:
          claimName: redis-pvc

Configuration Explained

• --tls-port 6379: Enable TLS on port 6379
• --port 0: Disable plaintext connections entirely
• --tls-auth-clients no: Don't require client certificates (use password instead)
• --requirepass: Require password authentication

Kubernetes Secret

apiVersion: v1
kind: Secret
metadata:
  name: redis-tls
  namespace: bakery-ia
type: Opaque
data:
  redis-cert.pem: <base64-encoded-certificate>
  redis-key.pem: <base64-encoded-private-key>
  ca-cert.pem: <base64-encoded-ca-certificate>

Create from files:

kubectl create secret generic redis-tls \
  --from-file=redis-cert.pem=infrastructure/tls/redis/redis-cert.pem \
  --from-file=redis-key.pem=infrastructure/tls/redis/redis-key.pem \
  --from-file=ca-cert.pem=infrastructure/tls/redis/ca-cert.pem \
  -n bakery-ia

---

Client Configuration

PostgreSQL Client Configuration

Services connect to PostgreSQL using asyncpg with SSL enforcement.

Connection String Format:

# Base format
postgresql+asyncpg://user:password@host:5432/database

# With SSL enforcement (automatically added)
postgresql+asyncpg://user:password@host:5432/database?ssl=require

Implementation in shared/database/base.py:

class DatabaseManager:
    def __init__(self, database_url: str):
        # Enforce SSL for PostgreSQL connections
        if database_url.startswith('postgresql') and '?ssl=' not in database_url:
            separator = '&' if '?' in database_url else '?'
            database_url = f"{database_url}{separator}ssl=require"

        self.database_url = database_url
        logger.info(f"SSL enforcement added to database URL")

Important: asyncpg uses ssl=require, NOT sslmode=require (psycopg2 syntax).

Redis Client Configuration

Services connect to Redis using TLS protocol.

Connection String Format:

# Base format (without TLS)
redis://:password@redis-service:6379

# With TLS (rediss:// protocol)
rediss://:password@redis-service:6379?ssl_cert_reqs=none

Implementation in shared/config/base.py:

class BaseConfig:
    @property
    def REDIS_URL(self) -> str:
        redis_host = os.getenv("REDIS_HOST", "redis-service")
        redis_port = os.getenv("REDIS_PORT", "6379")
        redis_password = os.getenv("REDIS_PASSWORD", "")
        redis_tls_enabled = os.getenv("REDIS_TLS_ENABLED", "true").lower() == "true"

        if redis_tls_enabled:
            # Use rediss:// for TLS
            protocol = "rediss"
            ssl_params = "?ssl_cert_reqs=none"  # Don't verify self-signed certs
        else:
            protocol = "redis"
            ssl_params = ""

        password_part = f":{redis_password}@" if redis_password else ""
        return f"{protocol}://{password_part}{redis_host}:{redis_port}{ssl_params}"

Why ssl_cert_reqs=none?

• We use self-signed certificates for internal cluster communication
• Certificate validation would require distributing CA cert to all services
• Network isolation provides adequate security within cluster
• For external connections, use ssl_cert_reqs=required with proper CA

---

Deployment

Full Deployment Process

Option 1: Fresh Cluster (Recommended)

# 1. Delete existing cluster (if any)
kind delete cluster --name bakery-ia-local

# 2. Create new cluster with encryption enabled
kind create cluster --config kind-config.yaml

# 3. Create namespace
kubectl apply -f infrastructure/kubernetes/base/namespace.yaml

# 4. Create TLS secrets
kubectl apply -f infrastructure/kubernetes/base/secrets/postgres-tls-secret.yaml
kubectl apply -f infrastructure/kubernetes/base/secrets/redis-tls-secret.yaml

# 5. Create ConfigMap with PostgreSQL config
kubectl apply -f infrastructure/kubernetes/base/configmaps/postgres-logging-config.yaml

# 6. Deploy databases
kubectl apply -f infrastructure/kubernetes/base/components/databases/

# 7. Deploy services
kubectl apply -f infrastructure/kubernetes/base/

Option 2: Update Existing Cluster

# 1. Apply TLS secrets
kubectl apply -f infrastructure/kubernetes/base/secrets/postgres-tls-secret.yaml
kubectl apply -f infrastructure/kubernetes/base/secrets/redis-tls-secret.yaml

# 2. Apply PostgreSQL config
kubectl apply -f infrastructure/kubernetes/base/configmaps/postgres-logging-config.yaml

# 3. Update database deployments
kubectl apply -f infrastructure/kubernetes/base/components/databases/

# 4. Restart all services to pick up new TLS configuration
kubectl rollout restart deployment -n bakery-ia \
  --selector='app.kubernetes.io/component=service'

Applying Changes Script

A convenience script is provided:

./scripts/apply-security-changes.sh

This script:

1. Applies TLS secrets
2. Applies ConfigMaps
3. Updates database deployments
4. Waits for pods to be ready
5. Restarts services

---

Verification

Verify PostgreSQL TLS

# 1. Check SSL is enabled
kubectl exec -n bakery-ia <postgres-pod> -- sh -c \
  'psql -U $POSTGRES_USER -d $POSTGRES_DB -c "SHOW ssl;"'
# Expected output: on

# 2. Check TLS protocol version
kubectl exec -n bakery-ia <postgres-pod> -- sh -c \
  'psql -U $POSTGRES_USER -d $POSTGRES_DB -c "SHOW ssl_min_protocol_version;"'
# Expected output: TLSv1.2

# 3. Check listening on all interfaces
kubectl exec -n bakery-ia <postgres-pod> -- sh -c \
  'psql -U $POSTGRES_USER -d $POSTGRES_DB -c "SHOW listen_addresses;"'
# Expected output: *

# 4. Check certificate permissions
kubectl exec -n bakery-ia <postgres-pod> -- ls -la /tls/
# Expected output:
# -rw------- 1 postgres postgres ... server-key.pem
# -rw-r--r-- 1 postgres postgres ... server-cert.pem
# -rw-r--r-- 1 postgres postgres ... ca-cert.pem

# 5. Verify certificate details
kubectl exec -n bakery-ia <postgres-pod> -- \
  openssl x509 -in /tls/server-cert.pem -noout -dates
# Shows NotBefore and NotAfter dates

Verify Redis TLS

# 1. Check Redis is running
kubectl get pods -n bakery-ia -l app.kubernetes.io/name=redis
# Expected: STATUS = Running

# 2. Check Redis logs for TLS initialization
kubectl logs -n bakery-ia <redis-pod> | grep -i "tls"
# Should show TLS port enabled, no "wrong version number" errors

# 3. Test Redis connection with TLS
kubectl exec -n bakery-ia <redis-pod> -- redis-cli \
  --tls \
  --cert /tls/redis-cert.pem \
  --key /tls/redis-key.pem \
  --cacert /tls/ca-cert.pem \
  -a $REDIS_PASSWORD \
  ping
# Expected output: PONG

# 4. Verify TLS-only (plaintext disabled)
kubectl exec -n bakery-ia <redis-pod> -- redis-cli -a $REDIS_PASSWORD ping
# Expected: Connection refused (port 6379 is TLS-only)

Verify Service Connections

# 1. Check migration jobs completed successfully
kubectl get jobs -n bakery-ia | grep migration
# All should show "COMPLETIONS = 1/1"

# 2. Check service logs for SSL enforcement
kubectl logs -n bakery-ia <service-pod> | grep "SSL enforcement"
# Should show: "SSL enforcement added to database URL"

# 3. Check for connection errors
kubectl logs -n bakery-ia <service-pod> | grep -i "error"
# Should NOT show TLS/SSL related errors

# 4. Test service endpoint
kubectl port-forward -n bakery-ia svc/auth-service 8001:8001
curl http://localhost:8001/health
# Should return healthy status

---

Troubleshooting

PostgreSQL Won't Start

Symptom: "could not load server certificate file"

Check init container logs:

kubectl logs -n bakery-ia <pod> -c fix-tls-permissions

Check certificate permissions:

kubectl exec -n bakery-ia <pod> -- ls -la /tls/

Expected:

• server-key.pem: 600 (rw-------)
• server-cert.pem: 644 (rw-r--r--)
• ca-cert.pem: 644 (rw-r--r--)
• Owned by: postgres:postgres (70:70)

Symptom: "private key file has group or world access"

Cause: server-key.pem permissions too permissive

Fix: Init container should set chmod 600 on private key:

chmod 600 /tls/server-key.pem

Symptom: "external-db-service:5432 - no response"

Cause: PostgreSQL not listening on network interfaces

Check:

kubectl exec -n bakery-ia <pod> -- sh -c \
  'psql -U $POSTGRES_USER -d $POSTGRES_DB -c "SHOW listen_addresses;"'

Should be: * (all interfaces)

Fix: Ensure listen_addresses = '*' in postgresql.conf

Services Can't Connect

Symptom: "connect() got an unexpected keyword argument 'sslmode'"

Cause: Using psycopg2 syntax with asyncpg

Fix: Use ssl=require not sslmode=require in connection string

Symptom: "SSL not supported by this database"

Cause: PostgreSQL not configured for SSL

Check PostgreSQL logs:

kubectl logs -n bakery-ia <db-pod>

Verify SSL configuration:

kubectl exec -n bakery-ia <db-pod> -- sh -c \
  'psql -U $POSTGRES_USER -d $POSTGRES_DB -c "SHOW ssl;"'

Redis Connection Issues

Symptom: "SSL handshake is taking longer than 60.0 seconds"

Cause: Self-signed certificate validation issue

Fix: Use ssl_cert_reqs=none in Redis connection string

Symptom: "wrong version number" in Redis logs

Cause: Client trying to connect without TLS to TLS-only port

Check client configuration:

kubectl logs -n bakery-ia <service-pod> | grep "REDIS_URL"

Should use: rediss:// protocol (note double 's')

---

Maintenance

Certificate Rotation

Certificates expire October 2028. Rotate 90 days before expiry.

Process:

# 1. Generate new certificates
cd infrastructure/tls
./generate-certificates.sh

# 2. Update Kubernetes secrets
kubectl delete secret postgres-tls redis-tls -n bakery-ia
kubectl create secret generic postgres-tls \
  --from-file=server-cert.pem=postgres/server-cert.pem \
  --from-file=server-key.pem=postgres/server-key.pem \
  --from-file=ca-cert.pem=postgres/ca-cert.pem \
  -n bakery-ia
kubectl create secret generic redis-tls \
  --from-file=redis-cert.pem=redis/redis-cert.pem \
  --from-file=redis-key.pem=redis/redis-key.pem \
  --from-file=ca-cert.pem=redis/ca-cert.pem \
  -n bakery-ia

# 3. Restart database pods (triggers automatic update)
kubectl rollout restart deployment -n bakery-ia \
  -l app.kubernetes.io/component=database
kubectl rollout restart deployment -n bakery-ia \
  -l app.kubernetes.io/component=cache

Certificate Expiry Monitoring

Set up monitoring to alert 90 days before expiry:

# Check certificate expiry date
kubectl exec -n bakery-ia <postgres-pod> -- \
  openssl x509 -in /tls/server-cert.pem -noout -enddate

# Output: notAfter=Oct 17 00:00:00 2028 GMT

Recommended: Create a Kubernetes CronJob to check expiry monthly.

Upgrading to Mutual TLS (mTLS)

For enhanced security, require client certificates:

PostgreSQL:

# postgresql.conf
ssl_ca_file = '/tls/ca-cert.pem'
# Also requires client to present valid certificate

Redis:

redis-server \
  --tls-auth-clients yes  # Change from "no"
  # Other args...

Clients would need:

• Client certificate signed by CA
• Client private key
• CA certificate

---

Related Documentation

Security Documentation

• Database Security - Complete database security guide
• RBAC Implementation - Access control
• Security Checklist - Deployment verification

Source Documentation

• TLS Implementation Complete
• Security Implementation Complete

External References

• PostgreSQL SSL/TLS Documentation
• Redis TLS Documentation
• TLS Best Practices

---

Document Version: 1.0 Last Review: November 2025 Next Review: May 2026 Owner: Security Team