Service Mesh Platform  ·  View 16 of 31  ·  5 · Runtime

Certificate Issuance and Rotation

How a sidecar gets an identity it did not choose, renews it with no restart, and how the cluster CA renews itself independently.

Editable source SVG draw.io All views
Envoy sidecar SPIRE agent kubelet SPIRE server OpenBao PKI Peer proxy 1. SDS: fetch SVID (Workload API) 2. which pod owns this PID? 3. namespace · service account · labels 4. CSR for attested selectors 5. match entry · write issuance record 6. SVID 24 h + trust bundle 7. push SVID and bundle 8. mTLS handshake 9. t + 12 h: renew 10. rotated SVID · no restart 11. renew 7-day CA at half-life 12. CA signed by c07 intermediate Certificate Issuance and Rotation — Attested, Never Asserted The pod never names itself. Its identity comes from what the kubelet reports about the process on a node the server has already attested. v 1.0 · owner Security Architecture · date 2026-09

Decisions

  • The selectors come from the kubelet and from a node the server has already attested with a projected service-account token. Nothing the pod says about itself is an input.
  • The issuance record is written by the server at signing time: serial, SPIFFE ID, node attestation, workload selectors, issuing CA. That is the evidence an auditor asks for.
  • Envoy receives rotated certificates over SDS and swaps them in memory. Existing connections finish on the old certificate; new ones use the new one.

Targets

  • Issuance p99 ≤ 2 s. 200 issuances a second sustained, 2,000 a second during a mass restart. At 2,000 proxies per cluster, the whole cluster re-issues in about a second of server time.

To prove

  • SPIRE server throughput against a CloudNativePG datastore at 2,000 issuances a second, with registration entries generated by spire-controller-manager for 2,000 pods per cluster.
◀  Telemetry Pipeline All views Root Rotation  ▶
Solution Architecture v1.0 · Platform Networking Architecture · 2026-09 · 31 views · open source, fully on-premises16-certificate-issuance-and-rotation