Linkerd Trust Anchor Rotation Without Downtime

Skip to main content

Pricing<br>Resources

Academy

About

Contact usDocs

Get Service Mesh Certified with Buoyant.<br>Enroll now!

Blog home<br>A 2026 Guide to Linkerd Trust Anchor Rotation with cert-manager

Linkerd Production Readiness Pre-Launch Checklist

Download checklist

Heading

Relevant articles<br>Linkerd vs Istio

eBPF, Sidecars, and the<br>Future of The Service Mesh

A Kubernetes engineer’s guide to mTLS

Tomáš Jamrich

July 22, 2026

Linkerd

You'll never get a 2am call for an expired leaf certificate, because every Linkerd proxy gets a workload certificate that is valid for 24 hours and rotates it automatically before it expires. You can run for years and never think about them.<br>The trust anchor is a different story, though. It’s the root every certificate chains back to. Every proxy is configured to trust it, and nothing rotates it for you. Being long-lived, it slips off the radar until the day it expires, and when it does, it fails quietly: existing traffic keeps flowing, so nothing looks broken, but the next pod to restart can’t rejoin the mesh.<br>To avoid all that, you need to rotate it ahead of time, and you need to do it without dropping a request. It's all a matter of the order of operations. Get it wrong and you'll cause the outage you were avoiding. In this blog post, I'll cover the rotation on Linkerd with cert-manager and trust-manager, the failure modes to plan for, and everything you need to know to avoid that outage.<br>Environment prerequisites for trust anchor rotation<br>a local kind cluster with 2 workers, so mTLS crosses hosts<br>Cilium as the container network interface (CNI) in kube-proxy-replacement mode<br>Linkerd edge-26.6.3<br>cert-manager and trust-manager for the certificate chain<br>emojivoto and its `vote-bot` for generating meshed traffic<br>kubectl, step, and jq for inspecting certificates along the way<br>The Cilium flag that matters for any mesh is socketLB.hostNamespaceOnly: true. Without it, Cilium rewrites the ClusterIP at the socket level before traffic reaches the proxy, and east-west mTLS silently stops.<br>Visit Linkerd's getting started and Helm installation docs for more details on setup. Linkerd runs in externalCA mode. It reads its roots from cert-manager and trust-manager instead of generating its own.<br>identity:<br>externalCA: true # trust roots come from a trust-manager ConfigMap<br>issuer:<br>scheme: kubernetes.io/tls # issuing CA read from a cert-manager Secretcert-manager creates and renews the chain. A self-signed-type ClusterIssuer creates the root-blue trust anchor, a 1-year ECDSA P-256 root. The anchor signs the identity issuer, a 90-day intermediate that cert-manager renews on its own. Both lifetime values are sensible choices, not constants Linkerd requires.<br># identity issuer (intermediate CA), signed by the anchor<br>spec:<br>commonName: identity.linkerd.cluster.local<br>duration: 2160h # 90 days<br>renewBefore: 720h # 30 days<br>issuerRef:<br>name: root-blue # repointed to root-green during rotationtrust-manager handles distribution. A Bundle is the list of trusted anchors. It writes them into the linkerd-identity-trust-roots ConfigMap that every proxy reads, starting with root-blue as the source. Most of the rotation is editing that list.<br>Traffic comes from emojivoto, Linkerd’s own demo app, and its built-in vote-bot, which sends a constant stream of meshed requests. When trying this on your own, keep in mind that emojivoto deliberately returns an error for votes on one specific emoji, so its overall success rate sits below 100%, whether it rotated or not.<br>One root to rule them all: Understanding the Linkerd identity hierarchy<br>Linkerd’s identity is a 3-tier hierarchy: a trust anchor, an identity issuer, and the workload certificates it signs. Each has a different job, lifetime, and storage, and the rotation touches them in a set order.<br>Trust anchor is the self-signed root, typically valid for a long time. Its only job is signing the issuer. Proxies validate peers with its public certificate, so the private key never has to reach them. cert-manager keeps that key in the cluster here for convenience. Don't do that in production, though.<br>Identity issuer is the intermediate that signs every workload certificate. Its cert and key both live in the cluster because the identity service signs with them constantly. Keeping that key in the cluster is why the issuer is short-lived and renewed automatically, so a leaked Secret expires within months rather than years.<br>Workload certificate is the 24-hour leaf. The proxy generates the key at startup and keeps it in memory. It never touches the disk. The cert carries the workload’s service account as a SPIFFE ID.

Linkerd’s signing chain: the self-signed trust anchor signs the identity issuer, which signs the workload certificate.With the exception of the in-memory workload certificate, each of these is verifiable against the cluster. The trust bundle is a ConfigMap, and it holds only the public certificates.<br>kubectl -n...