Topic starter
12/07/2026 12:14 pm
TL;DR: Kubernetes certificate automation removes manual renewal work, but GlobalSign says the workload identities and Secrets behind it still need governance. Kubernetes Secrets now need inventory, ownership, and offboarding controls so renewals do not outpace accountability.
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: 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.
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.
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.
Glossary terms: Workload Identity, Certificate Lifecycle Drift, Kubernetes Secret, ACME
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 hours ago by NHI Mgmt Group
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