Notifications
Clear all
Topic starter
12/07/2026 12:14 pm
TL;DR: Manual certificate management in Kubernetes creates renewal risk, operational drag, and authentication gaps, while ACME plus cert-manager automates issuance and renewal for cluster workloads according to GlobalSign. The governance issue is not whether automation is useful, but whether teams can prove lifecycle control over the secrets and workload identities behind it.
NHIMG editorial — based on content published by GlobalSign: Kubernetes certificate automation with ACME and cert-manager
Questions worth separating out
Q: What breaks when Kubernetes certificate automation is not tied to ownership?
A: Renewal can still succeed while the wrong workloads, namespaces, or service accounts keep valid trust material.
Q: Why do Kubernetes certificates create a governance issue for IAM teams?
A: Because certificates, Secrets, and workload identities are part of the access plane, not just infrastructure plumbing.
Q: How do teams know whether certificate automation is actually working?
A: Look for fewer human-mediated renewals, cleaner ownership records, lower expiry-driven outage rates, and reliable reporting across hybrid systems.
Practitioner guidance
- Map certificate ownership to workload owners Create a register that links each certificate, Kubernetes Secret, namespace, and consuming service account to a named owner and a retirement date.
- Audit Secret scope and access paths Review which identities can read certificate-bearing Secrets, then reduce namespace and service account reach to the minimum required for runtime use.
- Instrument renewal and revocation telemetry Track certificate issuance, renewal, failure, and revocation as auditable events, and alert when a workload renews outside its expected ownership pattern.
What's in the full article
GlobalSign's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step cert-manager setup using Helm or kubectl in a Kubernetes cluster.
- Issuer and ClusterIssuer configuration examples for an ACME endpoint.
- Certificate resource definitions showing how domain names and renewal settings are specified.
- The ACME challenge workflow and how the resulting certificate is stored in a Kubernetes Secret.
👉 Read GlobalSign's analysis of ACME-based certificate automation for Kubernetes →
Kubernetes certificate automation - are workload identities governed?
Explore further
12/07/2026 12:28 pm
Certificate automation is an NHI governance problem, not just a platform optimisation. In Kubernetes, certificates and the Secrets that store them function as workload identity material, so they need ownership, lifecycle, and revocation controls. Automation reduces human error, but it does not remove the need to know which workload has which credential, for how long, and under whose authority. The practitioner conclusion is simple: manage automated certificates as governed non-human identities.
A question worth separating out:
Q: Who should be accountable for certificate-backed workload access in Kubernetes?
A: Accountability should sit with the team that owns the workload, with platform and IAM functions providing the policy and telemetry. If no one owns renewal, revocation, and offboarding decisions, certificate automation becomes a shared blind spot rather than a control.
👉 Read our full editorial: Kubernetes certificate automation exposes workload identity governance gaps
