Executive Overview
Kubernetes and microservices architectures were adopted for resilience, scalability, and development velocity, and they have delivered on those goals. They have also quietly multiplied the number of APIs an enterprise operates, most of which never cross a network perimeter a traditional security tool would inspect. Red Hat's State of Kubernetes Security Report: 2024 Edition, based on a survey of 600 DevOps, engineering, and security professionals, found that 90% of organizations experienced at least one Kubernetes or container security incident in the past year, that 67% had delayed or slowed a production deployment due to security concerns, and that 46% experienced measurable revenue or customer loss as a direct result of a container or Kubernetes security incident [1]. This Expert Insight argues that the underlying cause is not primarily a tooling gap. It is a governance gap between how quickly microservices architectures create new internal APIs and how slowly most organizations extend API governance to cover them.
Figure 1. Kubernetes security incident impact, 600 organizations surveyed (Red Hat).
Core Insight
Most enterprise API governance programs, including the inventory, authentication, and monitoring practices built up over the last several years, were designed with external and partner-facing APIs in mind. Microservices architectures built on Kubernetes generate a different category of API almost as a byproduct of normal operation: internal, service-to-service APIs that exist purely to let one microservice call another. A single customer transaction in a modern Kubernetes-based application might traverse a dozen or more of these internal API calls before a response is returned, and each one is a potential point of compromise that rarely receives the same governance attention as the external-facing API a customer or partner actually calls.
This is not a hypothetical gap. Research from Kong on microservices security challenges describes this internal traffic, commonly called east-west traffic, as operating largely invisible to traditional security tools: pods communicate by default without encryption, without authentication, and without monitoring, unless an organization has deliberately deployed a service mesh or equivalent control to change that default [3]. An attacker who compromises a single, low-value microservice, a logging service, for example, can frequently move laterally through this unmonitored internal API layer to reach far more sensitive services, entirely outside the visibility of edge security tools that only inspect traffic entering or leaving the cluster.
Market Context
Kubernetes adoption has moved well past early-adopter status. The Cloud Native Computing Foundation's own survey data shows the large majority of enterprises are now using or evaluating Kubernetes in production, and 91% of Kubernetes users operate in companies with more than 1,000 employees, meaning this is overwhelmingly a large-enterprise, high-complexity phenomenon rather than a niche technical choice [4]. That scale is precisely why the internal API governance gap matters at a business level rather than only a technical one.
Palo Alto Networks' Unit 42 threat intelligence team documented the practical consequence of this gap directly in 2026 research on current Kubernetes threats. Their analysis found suspicious activity consistent with stolen Kubernetes service account tokens, the credentials that let one internal service authenticate to another and to the Kubernetes API itself, in 22% of cloud environments analyzed in 2025 [2]. In one case study Unit 42 documented, attackers used a compromised production Kubernetes cluster's service account tokens to move laterally from that cluster directly into the core financial systems of a cryptocurrency exchange, a path that had nothing to do with any externally facing API or traditional network perimeter control [2]. In a second documented case, attackers exploited a critical public-facing application vulnerability, CVE-2025-55182, to execute commands inside Kubernetes workloads within two days of the vulnerability's public disclosure, a response time that leaves little margin for manual patching processes [2].
These incidents are consistent with the broader API threat data this campaign has already established. Wallarm's 2026 API ThreatStats Report found that 43% of vulnerabilities added to the CISA Known Exploited Vulnerabilities catalog in 2025 were API-related, and Akamai's 2026 State of the Internet security report found API attack volume per organization rose 113% year-over-year [5][6]. Kubernetes and microservices architectures are not a separate risk category from this broader API attack surface trend; they are one of its fastest-growing sources, generating internal APIs at a pace that exceeds what most governance processes were designed to track.
How the Governance Gap Becomes an Attack Path
It is worth being specific about the technical mechanics here, because the pattern is consistent across the incidents Unit 42 documented and is not particularly exotic. Kubernetes automatically mounts a service account token inside every pod by default, giving that pod's workload a way to authenticate to the Kubernetes API and, depending on its assigned permissions, to other internal services as well. This is a deliberate and useful design feature; it is also, in practice, a standing credential that persists for the lifetime of the pod and is frequently over-permissioned relative to what the specific workload actually needs to do.
Once an attacker achieves any form of code execution inside a single container, whether through a vulnerable public-facing application, a compromised base image, or a supply-chain dependency, that mounted service account token is immediately available to them without any additional credential theft required. From there, the attacker can interact directly with the Kubernetes API using the pod's own credentials, often without triggering the kind of alerting that a human logging in with stolen credentials would trigger, since the activity originates from infrastructure the cluster already trusts. Unit 42's research describes this specific technique, using a pod's mounted service account token to interact directly with the Kubernetes API after initial code execution, as an increasingly common method for automated credential harvesting observed in incidents from late 2025 into early 2026 [2].
Strategic Interpretation
The strategic error many organizations make is treating Kubernetes security and API governance as separate initiatives owned by separate teams, platform engineering for the former, application security or a central API governance function for the latter. The Unit 42 case studies above suggest this separation is precisely where risk accumulates: the compromised financial-systems path began with Kubernetes-specific credential theft and ended in an outcome that any API governance program would consider squarely within its remit, yet the initial compromise vector sat entirely within Kubernetes-specific tooling and monitoring that a typical API governance function does not directly own or observe.
A second strategic misread is treating internal, service-to-service APIs as inherently lower risk than external, customer- or partner-facing APIs, on the reasoning that they are not directly internet-exposed. The lateral-movement pattern Unit 42 documented depends specifically on this assumption being false: once an attacker gains any foothold inside a cluster, whether through a public-facing vulnerability, a compromised container image, or a misconfigured ingress rule, internal APIs become the primary path for expanding that foothold into something materially damaging, precisely because they were not built or governed with an assumption of hostile internal traffic.
Enterprise Implications
For enterprises running production workloads on Kubernetes, three implications follow directly from the evidence above. First, API inventory efforts that stop at externally facing and partner APIs are structurally incomplete; the internal, service-to-service API layer inside a Kubernetes cluster needs to be inventoried and governed using the same discipline, even though it never appears in a traditional API gateway's traffic logs. Second, service account token management deserves the same priority as customer credential management, given that Unit 42's research identifies token theft as an active, currently exploited technique rather than a theoretical risk. Third, the business impact data from Red Hat's survey- revenue loss, customer loss, and delayed deployments- indicates this is already a board-relevant issue in a meaningful share of enterprises, not a purely technical concern confined to platform engineering teams.
There is also an organizational implication that is easy to overlook. In most enterprises, the team most capable of extending governance to this internal API layer, platform engineering, does not report through the same chain as the team accountable for overall API governance and security posture. Closing the governance gap described in this Expert Insight is therefore not purely a technical exercise; it requires a deliberate decision about shared ownership, since neither team alone typically has both the technical access to instrument internal cluster traffic and the governance mandate to require it be done consistently across every cluster and namespace an organization operates.
CyberTech Intelligence Perspective
CyberTech Intelligence's assessment is that Kubernetes-based microservices architectures have effectively created a second, largely ungoverned API layer inside most enterprise environments, running parallel to the external API layer that governance programs were originally built to manage. The two layers are increasingly connected in practice, as the Unit 42 case studies show, but they remain largely separate in ownership, tooling, and governance attention. Closing this gap does not require abandoning existing API governance work; it requires deliberately extending the same inventory, authentication, and monitoring discipline already applied to external APIs to cover internal, service-to-service traffic as well, treating a Kubernetes cluster's internal API surface as a first-class governance target rather than an operational detail owned entirely by platform engineering.
Executive Actions
- Extend API inventory processes explicitly to include internal, service-to-service APIs running inside Kubernetes clusters, not only externally facing and partner-facing endpoints.
- Deploy a service mesh or equivalent control to bring encryption, authentication, and monitoring to east-west traffic that is unprotected by default.
- Treat Kubernetes service account tokens with the same rotation, scoping, and monitoring discipline applied to customer and administrative credentials.
- Establish a single point of accountability spanning platform engineering and API governance for Kubernetes-based internal API risk, rather than leaving it split between teams with no shared ownership.
- Prioritize rapid patching processes for public-facing application vulnerabilities that could provide initial access to a cluster, given Unit 42's documented two-day exploitation window following disclosure.
Conclusion
Kubernetes and microservices architectures did not introduce a new category of security risk so much as they multiplied an existing one, API risk, faster than most governance programs extended to cover it. The evidence reviewed here, from Red Hat's enterprise survey data to Unit 42's documented attack case studies, points to a consistent pattern: internal, service-to-service APIs running inside Kubernetes clusters are increasingly the path attackers use to convert a limited initial foothold into material business impact, precisely because they sit outside the governance and monitoring discipline applied to external APIs. Organizations that extend API governance to explicitly include this internal layer will close a gap the current threat data shows is already being actively exploited, and will do so using a technique, mounted service account token abuse, that is well understood and specifically documented rather than speculative.
Strengthen Kubernetes and Microservices API Governance with CyberTech Intelligence
CyberTech Intelligence helps platform engineering and security teams extend API governance to cover the internal, service-to-service API layer inside Kubernetes and microservices architectures, closing the gap between external API governance and internal cluster risk.
To assess how your Kubernetes and microservices environment maps against this governance gap, connect with CyberTech Intelligence for a Kubernetes API Governance Review.
References
[1] Red Hat. The State of Kubernetes Security Report: 2024 Edition. Red Hat, 2024. https://www.redhat.com/en/engage/state-kubernetes-security-report-2024
[2] Palo Alto Networks Unit 42. Understanding Current Threats to Kubernetes Environments. Unit 42, 2026. https://unit42.paloaltonetworks.com/modern-kubernetes-threats/
[3] Kong Inc. 10 Microservices Security Challenges & Solutions for 2025. Kong, 2025. https://konghq.com/blog/engineering/10-ways-microservices-create-new-security-challenges
[4] Cloud Native Computing Foundation. CNCF Annual Survey. CNCF, 2023.
[5] Wallarm. 2026 API ThreatStats Report. Wallarm, 2026. https://www.wallarm.com/reports/2026-wallarm-api-threatstats-report
[6] Akamai. 2026 State of the Internet: Apps, APIs, and DDoS Security Report. Akamai, 2026. https://www.akamai.com/newsroom/press-release/ai-transformation-at-risk-ap-is-emerge-as-the-primary-attack-surface-akamai-research-finds
