The mesh CA & trust chain

Issuance, custom roots, protecting signing keys.

Expert30 min · lesson 9 of 15

The mesh certificate authority is the trust anchor for every workload identity and every mTLS handshake in the cluster. How it is rooted, how it issues, and how it rotates determine both the security and the resilience of the whole mesh.

Issuance and the trust chain

The mesh CA (istiod in Istio, the identity service in Linkerd) issues each workload a short-lived certificate whose identity is the workload’s SPIFFE ID, derived from its Kubernetes service account. The workload’s proxy requests a certificate at startup, presents proof of its service-account identity, and receives a leaf certificate signed by the mesh CA; the trust chain roots in the mesh’s root certificate, which every proxy trusts. Because issuance is automatic and tied to the workload’s attested identity, there is no manual certificate provisioning and no shared key — the same "identity from platform facts" principle SPIRE uses.

the mesh trust chain
# root cert (mesh trust anchor, long-lived, tightly guarded)
# └─ intermediate (per-cluster, held by istiod / identity)
# └─ leaf cert per workload (SAN: spiffe://cluster.local/ns/prod/sa/api)
# short-lived (e.g. 24h or less), auto-rotated by the proxy
#
# Every proxy trusts the root; a leaf is verified up the chain during mTLS.
# Protect the root/intermediate signing keys like control-plane crown jewels.

Rotation, custom roots, and protecting the CA

Leaf certificates are short-lived and rotated automatically, so a compromised workload cert expires quickly — the mesh equivalent of SVID rotation. For production, teams often replace the mesh’s self-signed root with their own root or intermediate (backed by a real PKI or an HSM/Vault) so the mesh’s trust chains into the organization’s existing trust hierarchy and the root key is properly protected. The CA’s signing keys are the crown jewels: whoever controls them can mint any workload identity in the mesh, so guard them like control-plane secrets, rotate the intermediate on a schedule, and monitor the CA. A compromised mesh CA means every identity in the cluster is forgeable.

Mesh CA lifecycle
issue
root → intermediate → leaf
chain of trust
leaf = workload SPIFFE ID
from the service account
protect + rotate
short-lived leaves, auto-rotated
leak expires fast
custom root via real PKI/HSM
guard signing keys
The mesh CA issues identity to every workload. Short-lived leaves plus a well-protected root/intermediate keep the trust chain sound.
The mesh CA signing key can forge any identity
Anyone who obtains the mesh root or intermediate signing key can mint a valid certificate for any workload in the cluster, defeating mTLS and authorization entirely. Treat those keys as control-plane crown jewels — back them with a real PKI/HSM where possible, restrict access tightly, and monitor and rotate them.