Teams should separate the container build from the exposure layer. Package the application into a container, deploy it with a Kubernetes manifest, and place ingress in front of the service so only approved paths reach the workload. That keeps routing, access control, and external reachability outside the app itself, which is the right boundary for security and operational change.
Why the exposure boundary should move to Kubernetes, not the legacy app
When a legacy application moves from virtual machines to Kubernetes, the safest pattern is to keep the application focused on business logic and move traffic control to the platform boundary. That means the container image should package the workload, while Kubernetes service and ingress layers decide what can reach it. This reduces ad hoc networking, makes external exposure more explicit, and gives teams a consistent place to apply routing and access policy.
A useful mental model is that the app should no longer decide how it is reached. The platform should do that. In practice, that separation helps teams avoid embedding host-specific assumptions into the workload, and it limits the chance that later infrastructure changes force code changes. It also creates a cleaner path for gradual migration, because the same workload can be exposed differently without changing the application internals.
For containerised workloads, the boundary is not just architectural convenience, it is part of the security control set. The container image, the service abstraction, and the ingress controller each have different responsibilities. If those responsibilities blur, teams often end up with direct pod exposure, inconsistent port handling, or application-level logic that tries to manage network reachability. A safer design is to let the cluster own reachability and let the application remain unaware of external routing decisions.
How ingress, services, and manifests work together
The deployment manifest describes the workload, but the NIST SP 800-190 Container Security model is clear that image, registry, orchestrator, and runtime protections each need their own treatment. In a migration, that means building a container image for the legacy app, exposing it only through a Kubernetes Service, and placing ingress or an equivalent front door in front of that service. The ingress layer is where hostnames, TLS termination, and approved paths are handled, not inside the legacy application itself.
This division matters because Kubernetes gives you a set of reusable controls that are much easier to reason about than one-off VM firewall rules. A service provides a stable internal endpoint, while ingress governs what enters from outside the cluster. That lets teams change how traffic is published without rewriting the workload or revalidating every internal connection path. It also supports safer rollout patterns, because the external entry point can be controlled independently of the pod lifecycle.
If the legacy application still depends on fixed ports, hardcoded URLs, or direct host exposure, those dependencies should be treated as migration debt rather than design requirements. The safest approach is to preserve application behavior while replacing the exposure method. That keeps the application portable and reduces the number of places where security policy has to be replicated.
What teams should preserve during the migration
Teams should preserve the security intent of the old environment, not its exact topology. On virtual machines, that intent may have been expressed through host firewalls, reverse proxies, or network ACLs. In Kubernetes, the equivalent intent is usually expressed through ingress rules, service definitions, namespace boundaries, and workload permissions. The important point is to keep the trust boundary outside the application so the same security posture survives the platform change.
That is where the most common migration mistake shows up: teams expose the workload directly because it is faster, then plan to “tighten it later.” In practice, later often means the first external dependency is already in production. A better sequence is to define the public route first, verify that only the intended paths are reachable, and then bring the legacy workload behind that path. For an application that was never built for internet exposure, this boundary discipline is usually more important than any single Kubernetes feature.
The exposure layer should also be the place where operational change is absorbed. If TLS settings, hostnames, certificate rotation, or route policy need to change, those changes should not require redeploying the legacy app. That separation makes incident response and rollback simpler, and it avoids turning application releases into network-control releases.
Risk and Threat Considerations
Legacy applications often assume a friendly network and can fail badly when they are exposed too broadly during container migration. Direct pod exposure, weak ingress policy, or bypassed service boundaries can expand the attack surface, create accidental public reachability, and make lateral movement easier if one component is compromised.
Failure mechanism: Teams publish the workload before the ingress and service boundaries are fully defined, or they allow multiple paths to the same app, creating inconsistent control points and making it harder to prove what is actually exposed.
Impact: Attackers or unauthorised users may reach internal endpoints, exploit forgotten admin paths, or use an exposed route to move from a web-facing foothold into broader cluster or application access.
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 and NIST CSF 2.0 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 | Controls exposed paths between the cluster and external users. |
| AC-4 — Information Flow Enforcement | Ingress and service layers govern which traffic may reach the workload. | |
| CM-7 — Least Functionality | Legacy apps should expose only the minimum required ports and endpoints. | |
| Recommendation — Enforce boundary protection at ingress and block unauthorized direct access paths. Apply information flow enforcement to restrict approved routes to the application. Remove unnecessary listeners and publish only required application paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Access to exposed application paths should be limited to approved users and services. |
| Recommendation — Restrict access to published routes and verify only authorized identities can reach them. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Ingress and service boundaries are network security controls around the workload. |
| Recommendation — Define and enforce secure network paths for the exposed workload. | ||
Practitioner Guidance
What to verify: Confirm that the application is reachable only through the intended ingress path, and that direct pod access, node ports, and legacy host routes are blocked unless there is an explicit exception. If you cannot state the approved path in one sentence, the exposure design is not yet ready.
Implementation sequence: Start with a minimal container image, then define the Kubernetes Service, then add ingress and policy controls, and only after that open external access. This order keeps the exposure layer independent of the code path and reduces the chance that a temporary shortcut becomes the permanent architecture.
Practitioner takeaway: The safest migration pattern is to make external reachability a platform concern, because once the app itself starts carrying exposure logic, every later change becomes harder to secure and easier to misconfigure.
Related resources from NHI Mgmt Group
- How should teams implement zero trust on virtual machines without moving everything into Kubernetes first?
- Why do legacy application security tools create friction for fast-moving SaaS teams?
- How should security teams extend cloud security policies across virtual machines, Kubernetes, and bare-metal workloads?
- How should teams expose containerized applications safely through Kubernetes ingress?
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
