Cloud-native security programs often focus on public entry points such as gateways, load balancers and internet-facing routes. Internal APIs can receive less scrutiny because they are not reachable from outside the environment. But limited reachability is not the same as protection: once an attacker compromises a workload, permitted service-to-service traffic may expose additional systems.
The issue grows with the use of interconnected container environments. The CNCF’s 2025 Annual Cloud Native Survey, published in January 2026, found that 82% of container users run Kubernetes in production. In these environments, east-west traffic—the communication between services—supports normal operations. Yet teams may lack a complete inventory of which services call which internal endpoints, what those endpoints can do, and who is responsible for them.
A foothold can expose internal routes
One example illustrates how an initial compromise can become lateral movement. An attacker exploits a vulnerable parsing library in an image-processing worker that handles user uploads. Although the worker is considered low priority and does not hold sensitive data, its container provides a foothold inside the cluster.
If the attacker can read the worker’s mounted service account token, they may be able to use its permissions to list Services in the Kubernetes namespace and identify potential targets. In the scenario, the attacker finds a pricing-admin service that accepts requests without credentials because it was intended for use only inside the cluster. The attacker can then reach that service through traffic the network already permits.
The example highlights a gap between network location and access control. An endpoint being internal does not establish that every workload able to reach it should be allowed to use it. Untracked dependencies can leave active APIs with privileged functions and no clear owner or review process.
Identity needs route-level authorization
Mutual TLS can establish the identity of a calling workload, but it does not determine whether that workload should access a particular route. A service mesh or other security system may authenticate traffic while still allowing an authenticated caller to invoke functions unrelated to its role.
Authorization therefore needs to consider both the caller’s identity and the requested route. Policies should deny access when the caller has no legitimate reason to make the request. In the example, an image-processing worker should not need access to a pricing endpoint; an explicit policy can reject that call even if the worker is authenticated and network connectivity exists.
Workload credentials also require least-privilege controls. Broad Kubernetes or cloud permissions can increase the consequences of a stolen service account token. Teams can review role bindings, use short-lived credentials where available, and disable service account token mounts for workloads that do not need them. These measures reduce what an attacker can do after compromising a container.
Build segmentation from observed traffic
Kubernetes allows pod traffic by default when no applicable NetworkPolicies restrict it. NetworkPolicies can limit that communication, provided the cluster’s networking implementation supports and enforces them. However, policies created without a reliable picture of actual dependencies risk interrupting legitimate operations. Teams may respond by loosening rules, weakening the intended controls.
Observing service-to-service flows offers a practical starting point. Teams can record which services communicate, review the resulting map, and use it to define default-deny policies with explicit allowances for required connections. East-west traffic telemetry may come from a security platform or a service mesh; the important step is to review the inventory and translate it into maintained controls.
Assign owners to internal APIs
Technical controls do not resolve the underlying ownership problem. Public APIs often have product owners and established review cycles, while an internal endpoint may outlast the team or individual that created it. Security teams need an inventory that records a named owner and data classification for each internal API, alongside its purpose and legitimate callers.
Routes with no observed callers should be investigated before they are retired, since a lack of recent traffic alone may not establish that an endpoint is unused. Internal routes should also be included in threat modeling, not treated as outside the scope of review simply because they are private.
The central distinction is between reachability and permission. Network boundaries determine which workloads can send requests; identity, authorization and segmentation determine what those requests can accomplish. Applying the same ownership and access-control discipline to internal APIs as to public ones can limit the paths available after an initial compromise. Until internal endpoints have an accountable owner, defined access requirements and a reason to remain active, their risk can remain absent from the organization’s security inventory.
