If you mount a Secret into a container using subPath, Kubernetes does not push later updates into that file, so a renewed certificate never reaches the running pod. Mount the whole Secret as a directory instead, then make sure the application rereads the files or restarts when they change.
What the documentation says
The Kubernetes Secret documentation states that when a volume holds data from a Secret and that Secret is updated, Kubernetes tracks the change and updates the volume using an eventually consistent approach. It then adds a note: a container using a Secret as a subPath volume mount does not receive automated Secret updates.
The kubelet keeps a cache of the keys and values for Secrets used in volumes on that node, and the strategy it uses to detect changes comes from the kubelet configuration field named configMapAndSecretChangeDetectionStrategy. So even a correct mount is not instant.
Why this bites with certificates
A certificate manager renews a certificate and writes it to the Secret. The Secret is correct. The pod keeps serving the old file because the subPath mount was a one time copy at container start. The outage arrives on expiry day, long after the renewal "worked."
It is easy to reach for subPath because it lets you drop one file into a directory that already has other files, such as a config folder, without hiding the rest.
Fix the mount
Compare the two patterns.
| Pattern | Gets Secret updates | Typical use |
|---|---|---|
| Whole Secret as a directory | Yes, eventually | Certificate and key pair |
| subPath single file | No | One file into a shared directory |
Mount the Secret to its own directory such as a dedicated tls folder and point the server config at the files there. If a tool insists on a fixed path, a symlink or the application setting for the certificate path usually solves it.
Make the application notice
An updated file does nothing if the process loaded the certificate once at startup. Pick one:
- Use a server that rereads certificates on a signal or on file change. See reloading nginx without downtime.
- In Go, load certificates per handshake. See reloading certificates in Go.
- Add a sidecar or controller that restarts the pod after the Secret changes.
- Use a proxy that gets certificates by API rather than files. See Envoy SDS.
How to confirm it works
- Note the expiry date of the certificate the pod serves, using a TLS probe from another pod.
- Force a renewal, or edit a test Secret.
- Wait through the kubelet sync period and probe again.
- Check both the file contents in the container and the certificate presented on the wire. They can differ if the process did not reload.
Run this as a game day before production depends on it.
Where Safeguard fits
Safeguard does not rotate certificates. It scans container images and dependencies, builds SBOMs, and applies policies and gates before manifests ship. You can see the container side in the demo below.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a finding and note how an image scan reports what is baked in versus what is mounted at runtime.
Quick check
Does a normal Secret volume update on its own?
Yes, eventually. Kubernetes updates the volume with an eventually consistent approach, but subPath mounts are excluded.
Is the update immediate?
No. The kubelet caches Secret data and detects changes according to its configured strategy, so allow time.
Should I put a certificate in an environment variable instead?
The Secret documentation treats volumes as the way files stay in sync. Certificates are files by nature, so a directory mount plus a reload is the simpler path. Test any other approach in your own cluster.
Sources
Last reviewed: 19 October 2026.
