The main break is connectivity assumption. Kubernetes networking often uses NAT on pod IPs, which can prevent non-Kubernetes data plane proxies from reaching Kubernetes-based proxies directly. In that case, separate zones are needed so traffic is routed through a Zone Ingress. Without that structure, the deployment model no longer matches the real network path.
When one zone is really two different network paths
The break is not just naming, it is the routing assumption. A kubernetes cluster and a VM environment may both host workloads, but they do not expose those workloads through the same dataplane, addressability model, or ingress path. If teams collapse them into one zone, they often design for direct reachability that does not exist once pod networking, NAT, and proxy chaining are involved.
That matters because a zone is only useful if traffic can enter and leave it in the way the architecture expects. In Kubernetes, the effective source and destination seen by the network may differ from the pod IP you think you are using, which means the VM-side proxy or control point may not be able to reach the Kubernetes-side proxy directly. The result is a control-plane mismatch, not just an operational inconvenience.
When this happens, the correct response is usually to separate the zones and make the path explicit. A Zone Ingress becomes the boundary where traffic is normalized, routed, and policy-enforced, instead of assuming a flat bidirectional path across two environments that behave differently.
Why the cluster and VM boundary changes the security model
Kubernetes introduces abstractions that are materially different from a traditional VM subnet. Pods are ephemeral, service routing may be virtualized, and source IP preservation is not guaranteed in the same way as in a VM-only environment. That means connectivity rules written for a VM estate often fail when applied unchanged to a cluster, even if both are inside the same broader cloud account or network.
In practice, the boundary is also a trust boundary. A VM environment often relies on stable host identity and explicit network attachment, while Kubernetes relies on higher-churn workloads and platform-mediated networking. If teams treat both as one zone, they may accidentally inherit assumptions about direct access, inspection points, and return-path symmetry that the cluster cannot satisfy.
This is why the issue is architectural, not cosmetic. The deployment model has to match the real path packets take, especially when enforcement depends on intermediary proxies, NAT translation, or service-level ingress rules.
What teams usually get wrong when they merge the zones
The most common mistake is drawing zone boundaries around ownership or environment labels instead of actual traffic flow. Teams see “one production environment” and assume one security zone, then discover that the Kubernetes segment needs a distinct ingress pattern, a different source-destination trust model, and separate handling for east-west versus north-south traffic.
Another recurring failure is assuming that a control working in the VM segment will automatically work in the cluster segment. A proxy, firewall rule, or inspection service may be valid in both places conceptually, but invalid operationally if it depends on seeing the original source path or on a direct network route that Kubernetes does not expose.
At scale, this produces hidden fragility: paths work in a lab, fail under real service-to-service traffic, and then fail again when platform updates change the translation layer. The more automated the estate becomes, the more dangerous it is to rely on a zone definition that ignores the actual forwarding behavior.
Risk and Threat Considerations
Misclassifying Kubernetes and VM workloads as the same zone creates an exposure gap because traffic can bypass the intended enforcement point or fail open into an undocumented path. That weakens segmentation, makes troubleshooting harder, and can leave operators believing they have a single trust boundary when they actually have two incompatible ones.
Failure mechanism: NAT, service routing, and proxy chaining alter the observable source and destination, so the control plane cannot reliably reach or validate the Kubernetes side through the same path used for VMs. The result is a broken assumption about direct connectivity, which can undermine ingress policy, inspection, and access control.
Impact: Traffic may be routed around the intended boundary, or legitimate traffic may fail in ways that prompt unsafe workarounds. Over time, that can create shadow exceptions, inconsistent enforcement, and a false sense of segmentation assurance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Separate zones and ingress boundaries depend on enforcing network trust edges. |
| Recommendation — Enforce boundary controls at the real traffic crossing point, not at the assumed shared zone. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Network Segmentation | The issue is a segmentation mismatch between two environments with different path behavior. |
| Recommendation — Model Kubernetes and VM traffic as distinct trust zones with explicit policy enforcement. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | The question is about infrastructure path differences and the operational boundary they create. |
| Recommendation — Document and manage the network paths that separate Kubernetes from VM traffic flows. | ||
| CSA Cloud Controls Matrix | IVS — Infrastructure & Virtualization Security | Kubernetes and VM separation is an infrastructure and virtualization boundary issue. |
| Recommendation — Define distinct control points for virtualized platforms and container networking. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network Security | The answer hinges on securing and segmenting traffic across different network paths. |
| Recommendation — Validate that network security controls match the real routing and trust boundaries. | ||
Practitioner Guidance
What to verify: Confirm the actual packet path, not the logical ownership model. If the VM proxy cannot reach the Kubernetes proxy without an explicit ingress hop, treat that as a boundary design requirement rather than a tuning issue.
What good looks like: Each environment has a clearly documented ingress and return path, and policy is enforced where the traffic really crosses trust boundaries. The architecture should remain valid even when source IPs are translated or pods are rescheduled.
Decision rule: If routing, NAT, or proxy visibility differs between the two environments, do not collapse them into one zone; model the Kubernetes side as a distinct zone with its own ingress control and operational checks.
Practitioner takeaway: Zone design should follow traffic behavior, not organisational convenience. If the network path is not the same, the security zone is not the same either.
Related resources from NHI Mgmt Group
- What breaks when teams try to use one shared policy model across every isolated environment?
- How should teams build a Kubernetes cluster when they need a development environment versus a production-ready one?
- What breaks when teams treat JWT and OAuth as the same thing?
- What breaks when security teams treat compliance as the same thing as maturity?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
