Introduction

Kubernetes NetworkPolicy objects are allow rules, not ordered firewall rules. A "deny all" policy works by selecting pods and providing no allowed peers, while an "allow all" policy works by explicitly allowing all traffic for selected pods, which means combining both on the same pods can neutralize the isolation you expected.

How NetworkPolicy Evaluation Actually Works

A pod becomes isolated for ingress or egress when at least one matching policy selects it for that direction. After that, only traffic explicitly allowed by any matching policy is permitted. Policies do not override one another in a first-match or last-match sequence. Instead, the allowed traffic is the union of all allowed rules across all matching policies.

That is the key to understanding the common confusion around "deny all with allow all." If one policy denies everything by allowing nothing, and another policy allows everything, the effective result is allow everything for the selected direction.

Example of a Deny-All Policy

This policy isolates pods labeled app: api for both ingress and egress and allows nothing.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: api-deny-all
5spec:
6  podSelector:
7    matchLabels:
8      app: api
9  policyTypes:
10    - Ingress
11    - Egress

There are no ingress or egress rules, so all selected traffic directions are denied.

Example of an Allow-All Policy

This policy selects the same pods and explicitly allows traffic from anywhere and to anywhere.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: api-allow-all
5spec:
6  podSelector:
7    matchLabels:
8      app: api
9  policyTypes:
10    - Ingress
11    - Egress
12  ingress:
13    - {}
14  egress:
15    - {}

The empty rule objects mean all sources and all destinations are allowed. If both policies match the same pods, the allow-all policy wins in practice because it expands the union of allowed traffic to everything.

The Right Way to Use Deny-All as a Baseline

A useful pattern is:

1. create a deny-all baseline for a namespace or app tier
2. add narrow allow policies for only the traffic you want
3. avoid broad allow-all policies on the same selected pods

For example, allow only ingress from an ingress controller and egress to DNS:

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: api-allow-ingress-and-dns
5spec:
6  podSelector:
7    matchLabels:
8      app: api
9  policyTypes:
10    - Ingress
11    - Egress
12  ingress:
13    - from:
14        - namespaceSelector:
15            matchLabels:
16              kubernetes.io/metadata.name: ingress-nginx
17  egress:
18    - to:
19        - namespaceSelector:
20            matchLabels:
21              kubernetes.io/metadata.name: kube-system
22      ports:
23        - protocol: UDP
24          port: 53

This preserves the deny-all baseline while opening only the paths the workload really needs.

Two Important Operational Notes

First, NetworkPolicy enforcement depends on the container network interface plugin. If the cluster networking implementation does not enforce policies, the YAML objects may exist without changing traffic behavior.

Second, policies are namespace-scoped. A default-deny policy in one namespace does not automatically isolate pods in another namespace unless separate policies exist there too.

Common Pitfalls

• Expecting NetworkPolicy rules to behave like ordered firewall rules leads to incorrect reasoning. Kubernetes unions allowed traffic from all matching policies.
• Applying both deny-all and allow-all to the same pods cancels the isolation effect. The broad allow policy reopens the traffic.
• Forgetting to declare policyTypes can create partial isolation when you intended both ingress and egress control. State the directions explicitly.
• Assuming every cluster enforces NetworkPolicy can leave workloads exposed. Verify that the network plugin supports and enforces policies.
• Writing narrow policies without allowing DNS or required service dependencies often breaks applications immediately. Map actual traffic requirements before locking everything down.

Summary

• Kubernetes NetworkPolicy is additive: allowed traffic is the union of matching allow rules.
• A deny-all policy isolates pods by allowing nothing.
• An allow-all policy on the same pods effectively reopens all traffic.
• The usual secure pattern is deny-all first, then add only specific allow rules.
• Always confirm that your cluster network plugin actually enforces NetworkPolicy.