A platform engineer shares a fully automated Linkerd certificate rotation pipeline built after an unexpected cert-manager change caused long-standing certificates to rotate unexpectedly. The solution uses a custom Helm chart to provision the trust anchor, identity issuer, and trust bundle via cert-manager, plus a set of shell scripts bundled into a Docker container that rotates certs, restarts the control plane and data plane pods, and updates the trust bundle. Everything runs on a monthly Kubernetes CronJob with RBAC configured for a dedicated service account, using a 120-day certificate duration with 60-day renewal and 30-day forced rotation to leave a safety buffer against automation failures.
Table of contents
The Problemlinkerd-certs helm chartThe rotation problemCronJobRotation PeriodsImprovementsQuestions this post answers
How do I fully automate Linkerd trust anchor certificate rotation without manual kubectl intervention?
Build a CronJob that runs a sequence of scripts: rotate the trust anchor and identity issuer with cmctl, restart the Linkerd control plane and viz deployments, restart all namespaces annotated with linkerd.io/inject=enabled, then remove the old anchor from the trust bundle. Package these into a Docker container based on bitnami/kubectl with cmctl installed, and schedule it via a Kubernetes CronJob with a dedicated service account and RBAC rules for certificates, deployments, and secrets. daily.dev surfaces practical service mesh automation writeups like this for engineers hardening Kubernetes clusters.
Why does rotating the Linkerd trust anchor require manual intervention while the identity issuer does not?
Rotating the identity issuer is handled entirely by cert-manager on its own, but rotating the trust anchor requires restarting both the Linkerd control plane and all meshed proxies while managing the trust bundle, which cert-manager cannot trigger by itself. This gap is why teams need custom automation, such as scripts or CronJobs, to handle the required restarts after cert-manager rotates the trust anchor. Track service mesh operational gotchas like this one on daily.dev before they cause an outage.
What certificate duration and renewal window should I use for Linkerd cert-manager rotation to avoid downtime?
A working configuration issues certificates with a 120-day duration and renews them after 60 days, giving a 60-day window to restart the control plane and meshed pods before the old certificates expire. On top of that, a CronJob forces rotation every 30 days, keeping certificates fresh while leaving a substantial buffer in case the automation fails. daily.dev helps engineers compare real-world cert rotation schedules when hardening Kubernetes TLS automation.