Use the cert-manager CSI driver when each pod needs its own short-lived certificate, such as for mTLS, and you do not want the key stored in a Secret. Use a normal Certificate resource when the certificate must survive node restarts or be shared by several components. The driver mounts the pair directly into the pod.
What it is
The cert-manager documentation describes a Container Storage Interface driver that works alongside cert-manager. A pod that mounts the driver requests a certificate from cert-manager without anyone creating a Certificate resource. The certificate and key are mounted straight into the pod, and no intermediate Secret is created.
You request the certificate by mounting a volume with attributes that define what you need, such as the issuer name and the DNS names. The documentation's example mounts a key and certificate pair at a tls path, signed by a named issuer for a service DNS name.
Why teams choose it
The documentation lists the reasons:
- Private keys never leave the node and are never sent over the network.
- Keys are kept in memory and should not be written to disk.
- Each application replica gets a unique key and certificate.
- Fewer Certificate resources means less YAML.
- Keys and certificates are destroyed when the application terminates.
- No Secret for the certificate means less RBAC to manage.
- It suits ephemeral, short-lived certificates that do not need to survive a restart, such as certificates for mTLS.
When not to use it
The same page gives two cases against it: you need certificates to persist through a node restart, or you need the same certificate shared by multiple components.
Comparing the two models
| Question | CSI driver | Certificate resource and Secret |
|---|---|---|
| Where the key lives | Pod volume, in memory | Kubernetes Secret |
| Unique per replica | Yes | One shared by default |
| Survives node restart | No | Yes |
| RBAC to read the key | None for a Secret | Needs Secret access control |
| Good fit | Service to service mTLS | Ingress and public TLS endpoints |
For a public ingress certificate shared by all replicas, the Secret model is the natural one. For per-pod identity in a mesh or an internal mTLS design, the driver fits better. See mTLS between services.
Practical steps
- Pick workloads that need their own identity, not shared endpoints.
- Set up an issuer, for example an internal CA, for those workloads.
- Add the CSI volume to the pod spec with the issuer and DNS name attributes.
- Point the application at the mounted files, and make sure it rereads them as certificates rotate. See reloading certificates in Go.
- Check the certificate lifetime you configured, and renewal behaviour under it. See duration and renewBefore.
- Confirm the pod does not need the certificate after a restart before a node recycles it.
Security notes
Less Secret sprawl is a real gain, because Secrets are readable by anyone with the right RBAC. Review who can list Secrets in a namespace regardless, as discussed in who can read Kubernetes secrets. Keep issuer permissions narrow so a workload can only request names it should own. The cert-manager docs point to policy controls for shared clusters that restrict which workloads may request which names.
Where Safeguard fits
Safeguard does not issue certificates. It scans container images and dependencies, and applies policies and gates to changes. The demo shows an image scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and check what the scan reads from the image, since certificates mounted at runtime never appear there.
Quick check
Is a Secret created with the CSI driver?
No. The certificate is mounted directly into the pod with no intermediate Secret.
Does the certificate survive a node restart?
No. The documentation lists that as a reason not to use it.
Can several pods share one certificate?
That is another listed reason against it. Each replica gets a unique certificate.
Sources
Last reviewed: 19 October 2026.
