Repository navigation
End-to-end / transparent TLS for databases #2816
Description
Context
There is no transparent end-to-end TLS for databases today. Where TLS exists, it terminates (or is operator-managed) at the workload, and there is no story for reusing a single issued certificate across both the external exposure leg and intra-cluster traffic. Externally, databases are reached over a plain LoadBalancer Service per instance (packages/apps/postgres/templates/external-svc.yaml:7-11); internally there is no per-application encryption guarantee beyond whatever the CNI provides.
Goal
Explore encrypting database traffic end-to-end without terminating anywhere in between: reuse the cert-manager-issued certificate for both the external leg (Gateway TLS-passthrough, no gateway termination) and intra-cluster traffic, optionally complemented by CNI mesh encryption for east-west. The client validates the same certificate from outside or inside the cluster, and no hop in the path sees plaintext.
This depends on two pieces tracked in the same effort: a ca.crt-only trust-anchor object so tenants can validate the endpoint without holding the server private key, and Gateway TLS-passthrough routing for databases (so the external leg is not terminated). Both are prerequisites for a clean end-to-end design.
Acceptance
- A design proposal covering certificate reuse (external + internal) and the east-west encryption story.
- A recorded decision on whether to implement, with the trade-offs (CNI lock-in vs. application-level TLS) made explicit.
Part of #2811.
Activity
lexfrei commentedon Jul 14, 2026
Closing as completed. The acceptance criteria of this issue were a design proposal covering certificate reuse and a recorded decision on whether to implement, with the trade-offs made explicit. Both are delivered by
external-database-exposure, now merged in cozystack/community.The recorded decision is application-level, operator-owned TLS carried through a non-terminating gateway, chosen over edge termination and over CNI mesh encryption for the external leg. Its cost is booked openly rather than hidden: every external client must obtain and pin the interior
ca.crt, and an interior CA rotation requires those clients to re-fetch it.There is no separate implementation left to track under this number, because end-to-end TLS turns out to be a consequence of not terminating rather than a feature to build. In
mode: Passthroughthe gateway forwards the raw handshake, so the certificate an external client validates is byte-identical to the operator-issued certificate the database already presents internally. The two hooks it depends on already have homes: trust-anchor delivery (<release>-ca-cert) in #2814, and SAN coverage plus the passthrough listeners in #2815. East-west encryption, the other half of the original framing, is #2977.