What is a container firewall and do you need one?

A container firewall controls which containers, pods and external addresses may connect to each other. In Kubernetes the built-in version is NetworkPolicy, which works only when your network plugin enforces it. You usually need this control, because containers on one cluster can reach each other by default.

Why do containers need their own network rules?

Containers are short-lived, move between hosts and get new addresses all the time, so a rule written for an IP address goes stale quickly. NIST SP 800-190 notes that traditional network devices are often poorly suited to this, because they cannot see traffic between containers on the same host or keep up with changing addresses. It recommends orchestrator-aware network separation instead, using the cluster's own features.

By default, a Kubernetes pod accepts connections from other pods and can connect out to any destination. A compromised pod can therefore scan the cluster and reach the database next door.

How does Kubernetes NetworkPolicy work?

The Kubernetes documentation describes NetworkPolicy as a way to control traffic at layers 3 and 4, with rules for traffic within the cluster and between pods and the outside world. A policy selects pods and lists what is allowed in and out, identified by other pods, namespaces or IP blocks.

Three details matter. First, policies are enforced by the network plugin, and creating the object without a plugin that supports it has no effect. Second, a pod is not restricted in a given direction until some policy selects it for that direction. Third, policies cover connections made to and from pods, and traffic to and from the node running the pod is always allowed.

A constructed example

A cluster hosts a web front end, an orders service and a database in one namespace. With no policy, the front end can talk to the database directly, and so can anything an attacker runs in a compromised pod. Adding a default deny for the namespace and then three allow rules gives a short, readable result: the front end may call the orders service, the orders service may reach the database on its port, and nothing else is allowed. When a developer later adds a debugging pod, it cannot reach the database, which is the behavior you want.

What does NetworkPolicy not do?

It does not see inside the traffic. It works on addresses, ports and protocols, so it cannot block a malicious request on an allowed port. It does not authenticate the caller by identity. NIST SP 800-207A addresses that gap, describing zero trust for cloud-native applications built on service identities and authorization policy, in addition to network parameters.

Many teams add a service mesh or an application-aware gateway for identity and layer 7 rules, and a host or cloud firewall to protect nodes and control egress.

Do you need a commercial container firewall?

Often not at first. Start with NetworkPolicy and a plugin that enforces it, and add more where you find real gaps, such as layer 7 inspection, egress filtering by domain name, or a requirement to see all flows. Choose based on evidence from your own traffic.

How to check or apply this

1. Confirm that your network plugin enforces NetworkPolicy, and test with a policy that should block something.
2. Apply a default-deny policy to each namespace, for ingress and egress.
3. Add allow rules per service that name the exact pods and ports needed.
4. Restrict egress, so pods cannot call arbitrary internet destinations. Allow only what each needs.
5. Record the flows you expect and compare them with observed traffic to catch surprises.
6. Keep policies in version control and review them like code.
7. Add service identity and layer 7 rules where ports alone are too broad.

Quick check

Sources

• Kubernetes Network Policies
• NIST SP 800-190, Application Container Security Guide
• NIST SP 800-207A, Zero Trust Architecture Model for Cloud-Native Applications

Last reviewed: 18 October 2026.