Kubernetes solved a deployment problem and created an identity problem in the same motion. Every pod that needs to talk to another service needs to prove what it is, and in most clusters that proof takes the form of an X.509 certificate or a service account token with a lifetime measured in hours rather than years. Multiply that by the churn of a modern container estate and you get a machine identity population that changes shape continuously, at a volume no manual process can govern.
This is why certificate lifecycle management for cloud native platforms has become a non-human identity question rather than a purely operational one. The certificates are the credentials. Whoever controls issuance, renewal and trust anchors controls the access that thousands of workloads hold by default.
The scale problem is the risk problem
In a traditional data centre, a certificate authority estate was large, slow-moving and largely visible. Platform teams knew roughly how many certificates existed because they were ordered, tracked and renewed on a schedule someone owned. Container platforms invert all three assumptions. Certificates are issued programmatically, often by the platform itself, often with short validity and no central inventory. Rotation is automated because manual rotation at that volume is impossible.
The failure modes follow directly. Certificate expiry becomes an availability incident when automation breaks silently. Private keys end up in Kubernetes secrets that are readable by anyone with sufficient namespace permissions. Trust bundles spread across clusters and namespaces until nobody can state confidently which authorities are still honoured. And because none of this looks like a “user account”, it rarely enters the identity governance programme at all.
What mature programmes do differently
The pattern that holds up starts with treating the cluster as a credential factory that must be governed, not merely operated. Issuance policy becomes explicit: which workloads may request certificates, from which authority, for which identities and with what lifetime. That policy lives in code and is reviewed like code, rather than being an emergent property of whatever defaults shipped with the platform.
Visibility comes next. A useful test is whether the security team can answer, without asking the platform team, how many certificates exist across the estate, when each expires, which authority signed it and which workload presents it. If that answer requires a spreadsheet, the estate is not governed. Automatic discovery and inventory of certificates and keys is the prerequisite for everything else, including the AI agent inventories that boards are now asking about.
Then comes reduction of standing trust. Short-lived certificates are only an improvement if the trust anchors behind them are tightly held and the renewal path is observable. Where credentials must persist, they belong in a managed secrets store with rotation enforced, not in a manifest or an environment variable committed to a repository.
Policy, ownership and auditability
Tooling that automates issuance for cloud native workloads closes a real gap, but automation without ownership simply moves risk faster. The organisations getting this right assign a named owner for the certificate and key estate, define what “healthy” looks like across expiry, algorithm and authority, and alert on deviation rather than on outage. They also separate the ability to request a credential from the ability to approve the policy that permits it, so a compromised pipeline cannot mint its own trust.
Kubernetes will keep producing machine identities at a rate that dwarfs human headcount. The question for platform and identity teams is whether that population is inventoried, policy-bound and auditable, or whether it is simply running.