Envoy's secret discovery service, SDS, lets a central server push certificates to proxies over an API instead of baking them into files. When a certificate is replaced, Envoy uses the new one right away with no redeploy. The cost is a new dependency: the SDS connection must itself be secured, and a fetch failure changes how listeners behave.
The problem SDS solves
The Envoy documentation describes the file based alternative. In Kubernetes, certificates are created as Secrets and mounted into proxy containers. When a certificate expires, the Secret must be updated and the proxy containers redeployed. That is slow, easy to forget, and ties certificate hygiene to your release process.
With SDS, a central SDS server pushes certificates to all Envoy instances. If a certificate is near expiry, the server pushes a new one, and Envoy switches to it immediately, per the documentation.
Static, file based and SDS compared
| Approach | Rotation | Redeploy needed | Extra moving part |
|---|---|---|---|
| Static in bootstrap config | Edit config | Yes | None |
| Secret mounted as a file | Update the Secret, then reload or restart | Often | Reload logic |
| SDS from a server | Server pushes new secret | No | SDS server and its trust |
What happens when the fetch fails
This part of the documentation is worth reading before production. If a listener's server certificate must be fetched through SDS, the listener is not marked active and its port is not opened until the certificate arrives. If Envoy fails to fetch because of connection failures or bad response data, the listener is marked active and the port opens, but connections to it are reset.
Upstream clusters behave similarly. A cluster whose client certificate comes from SDS is not used until the certificate is fetched. If the fetch fails, the cluster is marked active, but requests routed to it are rejected.
So an SDS outage at startup yields closed ports or reset connections, not an insecure fallback. That is the safer direction, and it also means SDS availability affects service availability. Plan for it like any dependency.
Securing the SDS connection
The documentation says the connection between Envoy and the SDS server must be secure. One option is to run the SDS server on the same host and use a Unix domain socket. Otherwise, the connection needs TLS with authentication between the proxy and the SDS server. Credential types it lists for this authentication include mTLS, where the client certificates for the SDS connection must be statically configured, and AWS IAM SigV4.
Notice the bootstrap problem: the certificate that protects the SDS channel is static, so it needs its own rotation plan. Keep that credential narrow and long enough lived to rotate calmly.
Real implementations
Istio uses this model. Its agent monitors expiry and delivers renewed keys and certificates to Envoy via the SDS API. See Istio mTLS modes. The Envoy page also notes SPIRE as a source of identities, covered in SPIFFE and SPIRE.
Steps to adopt SDS
- List the certificates your proxies use today and how each gets rotated.
- Choose an SDS server, or use one built into your mesh.
- Secure the proxy to server channel with a socket or authenticated TLS.
- Test behaviour with the SDS server down at proxy start.
- Alert on SDS fetch errors and on the remaining lifetime of the served certificate.
- Drill a rotation and confirm clients see the new serial without a restart.
Where Safeguard fits
Safeguard does not run SDS. It provides continuous monitoring of dependencies, SBOMs and policy gates for the code and configuration around your proxies. The demo shows the monitoring view.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how ongoing checks catch a change that a one time review would miss.
Quick check
Does SDS need a redeploy to rotate?
No. According to the Envoy documentation, the server pushes the new certificate and Envoy uses it right away.
What if Envoy cannot fetch a listener certificate?
The port opens but connections are reset, rather than serving without the certificate.
Can the SDS channel be plaintext?
No. The documentation requires it to be secure, for example a Unix domain socket on the same host, or authenticated TLS.
Sources
Last reviewed: 19 October 2026.
