ADR 0009: Deploy to Kubernetes with Vault and OpenTelemetry
This record defines the production platform boundary.Context
The neobank requires horizontally scalable API and worker processes, protected credential encryption, migrations, and correlated operational evidence.Decision
Deploy generic Helm resources for web, API, worker, scheduler, and migration jobs. Use externally operated high-availability PostgreSQL, Redis, and Vault. Supply a short-lived, narrowly scoped Vault token through externally managed, workload-specific Kubernetes Secrets; the chart never renders secret values and disables automatic service-account token mounts. The API and worker receive only their required credentials, the scheduler receives only Redis, and the migration job receives only PostgreSQL. Require authenticated HTTPS transport to Vault in pilot and production. The API and worker images must trust the certificate authority that issued Vault’s serving certificate. Apply default-deny ingress and egress policies. Permit ingress only from the configured ingress controller namespace or another neobank workload. Restrict PostgreSQL, Redis, and Vault egress to their configured namespaces and ports; permit HTTPS egress for Auth0 and Perflo. Emit structured logs, Prometheus metrics, and OpenTelemetry traces with request, operation, and upstream correlation IDs. Redact personal and credential data before export.Consequences
The chart remains portable across self-hosted Kubernetes installations. Operators must provide backup, restore, key-management, and telemetry endpoints.Rejected alternatives
- Single virtual machine: it does not meet the requested production topology.
- Secrets in Helm values: rendered manifests and release state would expose them.