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.
Editorial analysis by NHI Mgmt Group, based on content published by GlobalSign: “Absicherung von Kubernetes-Clustern mit GlobalSigns ACME-Service und cert-manager”.
Key questions
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 workload certificates create NHI governance risk in Kubernetes?
A: Because the certificate is acting as a non-human identity credential, not just a transport-security artifact.
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
- Define certificate ownership for every workload Assign each certificate to a named workload owner, namespace, and renewal authority so the identity behind the Secret is always accountable.
- Inventory Kubernetes Secrets that carry trust Track every Secret created through cert-manager, including issuer source, workload consumer, and expiry date, so stale trust material is visible.
- Separate issuance from consumption privileges Restrict who can create Issuer and ClusterIssuer objects, and limit which workloads can read the resulting certificate Secrets.
Bottom line: Kubernetes certificate automation removes manual renewal work, but it does not remove the need to govern workload identities and the Secrets that hold them.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/07/2026 12:28 pm
Certificate automation is now a workload identity governance issue. In Kubernetes, the certificate lifecycle is inseparable from the identity of the service that presents it. Once issuance and renewal are automated, the operational question shifts from whether certificates expire on time to whether every certificate-backed workload has an owned identity, bounded scope, and revocation path. Practitioners should treat certificate automation as part of NHI governance, not a sidecar to infrastructure operations.
A few things that frame the scale:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
A question worth separating out:
Q: Should security teams treat Kubernetes Secrets as identity assets?
A: Yes. In this context, the Secret is the runtime container for a workload credential, so it belongs in identity governance as well as platform operations. If teams manage Secrets only as infrastructure objects, they miss ownership, revocation, and offboarding obligations that determine whether the workload can still be trusted.
👉 Read our full editorial: Kubernetes certificate automation exposes workload identity governance gaps