You have implemented Kubernetes network policies. Every namespace has ingress and egress rules. Your pods can only communicate with what they are explicitly permitted to communicate with. You have done the network segmentation work.
Then an attacker compromises your web application container and makes an outbound connection to an external C2 server. Your network policy said egress to port 443 is permitted for the application. The malicious connection looks identical to legitimate HTTPS traffic. The policy passes it through.
Network policies are a necessary security control. They are not a sufficient one. Understanding what they protect against — and what falls outside their protection — is the foundation of a coherent defense-in-depth strategy.
What Network Policies Actually Protect?
Kubernetes network policies operate at Layer 3/4 of the network stack. They enforce which pods can communicate with which other pods, which namespaces, and which external IP ranges, on which ports.
Network policies protect against:
- Lateral movement between pods and namespaces: A compromised pod cannot connect to a database in another namespace if network policy denies that connection.
- Unauthorized external access to services: Services not exposed through ingress rules are unreachable from outside the cluster.
- Broad port scanning: A compromised pod cannot scan the entire cluster network if egress is restricted.
Network policies do not protect against:
- Exploitation of vulnerabilities within allowed traffic: Your web application container receives HTTP requests on port 80. Network policy permits this. A malicious payload delivered via that allowed HTTP connection is invisible to network policy.
- Outbound connections over permitted ports: If your application legitimately needs HTTPS egress, an attacker who compromises the application can use that same permitted egress path.
- Vulnerabilities in the container image itself: The packages installed in your container image are not network policy concerns.
“Network segmentation stops attackers from moving between containers. It does not stop attackers from using the container they are in. That requires controlling what the container itself can do.”
The Execution Layer That Network Policies Cannot Reach
When an attacker achieves code execution inside a container, they are operating within the permissions and capabilities of that container process. Network policy determines what network connections the container can make. The container image determines what tools are available for exploitation.
Consider a compromised web application container. Network policy permits outbound HTTPS (port 443) because the application makes API calls. The attacker uses this permitted egress path for command-and-control communication.
Now consider the same scenario with an image that has been hardened by removing unused packages. The attacker is inside the container. They want to:
- Establish persistence: They look for a cron binary, a systemd utility, something to schedule code execution. None are present. The image had them removed.
- Explore the environment: They try ls, find, cat /etc/passwd. These binaries are absent from the hardened image.
- Exfiltrate data: They try curl, wget, nc. These are not present in the production image.
- Move laterally: They try to connect to other services. Without networking tools, their options are limited to what the application itself can connect to.
Container hardening applied to the image fundamentally changes what an attacker can do after initial access, in ways that network policy cannot.
The Complementary Relationship
Network policies and image hardening address different threat vectors. They are not substitutes for each other; they protect different layers.
Network policies protect the network layer: What can this container connect to? What external traffic can reach this container?
Image hardening protects the execution layer: What can code running inside this container do?
An organization that has strong network policies but unhardened images has protected the paths between containers while leaving the contents of each container exposed. An organization that has hardened images but no network policies has reduced what attackers can do inside a compromised container while leaving lateral movement paths open.
Defense-in-depth requires both.
Where to Apply Image Hardening After Network Policies Are in Place?
If you have already implemented network policies and are looking for the next security layer, image hardening is a natural progression. The prioritization:
Start with internet-facing containers: Your ingress layer — API servers, web servers, reverse proxies — receives traffic from the most adversarial external sources. These are the containers most likely to be targeted and the most important to harden.
Harden containers with database access: A compromised application container that retains a database connection is still dangerous after network policy blocks everything else. Hardening the application container limits what the attacker can do with that database connection.
Address containers with elevated permissions: Any container running with NET_ADMIN, SYS_PTRACE, or other elevated capabilities warrants immediate hardening attention. These capabilities expand what an attacker can do if the container is compromised.
Evaluate containers that make external egress calls: Containers that legitimately need external network access are the ones where container security software hardening provides the most incremental value over network policy alone. The egress path is open; what the attacker can use it for depends on what is installed in the image.
Frequently Asked Questions
Why are network policies important when managing a network?
Kubernetes network policies are important because they enforce least-privilege communication between workloads — by default, pods can communicate with any other pod in the cluster, which means a compromised container can attempt lateral movement freely. Network policies limit which pods can connect to which other pods, which namespaces, and which external endpoints, reducing the blast radius of a container compromise. However, they operate at Layer 3/4 and cannot inspect payload content or restrict what happens inside a container process, which is why container hardening is needed as a complementary layer.
How to ensure container image integrity?
Container image integrity is ensured through a combination of image signing (using tools like Cosign or Notary), admission controllers that block unsigned or unverified images from running, and continuous CVE scanning of all images in your registry. Image hardening — removing unused packages and minimizing the attack surface — further ensures that the running container contains only what the application requires, reducing the risk that a supply chain compromise or vulnerable dependency goes undetected.
What is the difference between Docker image and container image?
A Docker image is a specific format of container image built and managed using Docker tooling, while “container image” is the broader term that encompasses images in the OCI (Open Container Initiative) format used by any compliant runtime, including containerd, CRI-O, and Docker. In practice, the terms are often used interchangeably in Kubernetes contexts. For security purposes, both Docker images and OCI container images benefit from the same hardening practices: removing unused packages, scanning for CVEs, enforcing non-root execution, and maintaining a minimal package footprint.
How much does Docker hardened images cost?
The cost of hardened container images depends on the approach. Docker’s own hardened images are available through Docker Hub subscriptions. Third-party container hardening platforms like RapidFort automate the runtime-profiling and package-removal process across your own images, with pricing based on image volume and pipeline integration. For teams managing large image portfolios, the operational cost savings from reduced CVE triage burden — typically 80-90% fewer scanner findings — often exceed the tool cost within the first year.
The Combined Control State to Aim For
Mature container security programs operate with both layers functioning:
At the network layer: default-deny network policies with explicit egress and ingress allowances. No pod has unrestricted network access. External egress is allowed only for services that specifically require it.
At the execution layer: container images stripped of packages that do not serve the application’s runtime function. No shell, no package manager, no networking utilities unless the application requires them. Images rebuilt when base images update, with CVE assessment as a pipeline gate.
Together, these controls produce containers where network policy limits what they can connect to and image hardening limits what an attacker can do with any connection they can make. The combination is meaningfully more secure than either layer alone.
