Topic starter
30/07/2026 10:47 pm
TL;DR: Kubernetes service-to-service traffic is a growing attack surface, and mutual TLS reduces exposure by authenticating both ends of a connection while limiting the value of stolen credentials, according to GlobalSign. The governance challenge shifts to certificate provisioning, rotation, and deprovisioning at container scale, where identity lifecycle discipline matters as much as encryption.
Editorial analysis by NHI Mgmt Group, based on content published by GlobalSign: “Why mTLS Should Be Everywhere in Kubernetes and Not Just Entry and Exit”.
By the numbers:
- 96% of the more than 2,300 Kubernetes-specific respondents were either already using Kubernetes or evaluating it, according to the 2021 Cloud Native Computing Foundation Annual Survey cited by GlobalSign.
- The survey identified 5.6 million Kubernetes users, an increase of nearly 70% in a single year, according to the 2021 Cloud Native Computing Foundation Annual Survey cited by GlobalSign.
- In a survey by Veritas Technologies cited by GlobalSign, 94% of respondents expressed concern about ransomware attacks on Kubernetes environments.
Key questions
Q: What breaks when certificate lifecycle is not governed for workloads?
A: Trust becomes hard to validate consistently.
Q: Why does mTLS reduce risk in Kubernetes microservices environments?
A: mTLS reduces risk because it requires both sides of a connection to prove identity before data moves.
Q: What are the signs that Kubernetes certificate management is failing?
A: Common signs include manual renewals, inconsistent certificate distribution, surprise expirations, service downtime when certificates lapse, and poor visibility into where certificates are deployed.
Practitioner guidance
- Standardise workload certificate issuance Use a consistent issuance path for every Kubernetes service so certificate creation is tied to deployment and namespace identity, not handled manually.
- Automate rotation and revocation Set short certificate lifetimes and enforce automated renewal plus revocation so expired or orphaned service identities cannot persist across redeployments.
- Require mutual authentication on sensitive service paths Apply mTLS to microservice-to-microservice and service-to-API-server traffic where stolen credentials alone should never be sufficient to connect.
Bottom line: Kubernetes service communication now needs identity governance as much as encryption, because mTLS only protects what it can authenticate.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/07/2026 10:53 pm
mTLS is becoming a service identity control, not merely a transport control. In Kubernetes, the real security question is no longer whether traffic is encrypted, but whether the caller is a trusted workload with a valid identity and certificate state. That shifts governance from packet protection to workload authentication, which is where identity teams and platform teams now meet. The practical implication is that Kubernetes security programs should treat mTLS as part of identity architecture.
A few things that frame the scale:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
A question worth separating out:
Q: How should platform teams decide where to apply mTLS first in Kubernetes?
A: Start with the traffic that would cause the most harm if intercepted or spoofed, especially service-to-service calls carrying sensitive data and API requests that can trigger privileged actions. The first deployments should protect trust boundaries, not every low-value path, so the programme reduces risk where identity assurance matters most.
👉 Read our full editorial: mTLS in Kubernetes: securing service identity and data flows