Delivering Certs to a Pod: A Two-Stage Deploy Render
How certs get from a secret store onto a running service's disk: a two-stage render at deploy time, not a live call. By the time the app starts, the cert is just a file.
The certificates live in a secret store (a service whose whole job is to safely hold secrets like keys and certificates). The question is how they get from there onto the running service’s disk. The answer is a two-stage render at deploy time, not a live call to the secret store while the service runs:
- Pull-and-inline stage. During deployment, a template reads the certificate out of the secret store using the deploy identity, and pastes the certificate text straight into the deploy configuration.
- Package stage. A deploy tool turns that configuration into a stored secret inside the cluster, then mounts it as ordinary files in a directory (say
/…/config/certs). The app just reads plain files from there.
A few things worth pinning down:
- The running service never talks to the secret store. By the time the app starts, the certificate is already a file on disk. The secret store is out of the picture.
- The reader is the deploy identity, not the app. A deploy-time role does the reading, not the app’s own runtime role.
- Different certificates come from different issuers, by purpose. Public, auto-renewed certificates for the front door, and a private in-house issuer for the internal service-to-service certificates (rotated on a schedule, with a hard expiry).
- Machine logins to a secret store come in two shapes. One is a stable ID plus an on-demand secret. The other ties the login to the service’s cluster identity.
In this migration: the deploy reused an earlier service’s pattern. A config block reads the three certificate files (root_ca, certificate, private_key) from the secret store and mounts them. The deploy identity does the reading, not the app’s own role.
The service does not fetch the secret. The deploy already put it on disk.
References
Related: the three files it mounts are the certificate triad, and the front door’s cert is automated the same way (ingress TLS termination). Back to the overview: two SSLs behind one migration ticket.