A Namespace Without a Default-Deny NetworkPolicy Leaves Pods Open to All Traffic

Symptom

A namespace that engineers believed was isolated by NetworkPolicy continues to accept traffic from pods and namespaces that were never explicitly granted access. Traffic that the team assumed was blocked reaches workloads without error, warning or denial event of any kind, and nothing in kubectl get networkpolicy output indicates a problem because the applied policy looks correct in isolation.

False Assumption

The team assumed that creating any NetworkPolicy object in a namespace switches that namespace into a default-deny posture, so that only explicitly allowed traffic can reach the selected pods. This is not how Kubernetes NetworkPolicy semantics work. A NetworkPolicy only affects the specific pods matched by its podSelector and only restricts the traffic types it names in policyTypes. Pods not selected by any policy remain fully open to all ingress and egress, exactly as if no NetworkPolicy resource existed in the namespace at all.

Root Cause

The observed exposure traces to a namespace that contains one NetworkPolicy scoped with a narrow podSelector (for example, matching only pods labelled app: payments-api) and an ingress rule allowing traffic from a specific frontend label. No separate policy exists with an empty podSelector: {} that would apply default-deny to every other pod in the namespace. Kubernetes NetworkPolicy is additive and selector-scoped, not namespace-wide by default; the presence of one policy does not imply a baseline deny for unselected workloads. Any pod in the namespace outside that selector, including newly deployed services, remains unrestricted.

Impact

Newly deployed or unlabelled workloads in the namespace inherit no network restriction whatsoever, so lateral movement between pods, direct pod-to-pod access bypassing intended service boundaries, and unintended cross-namespace ingress are all possible without triggering any policy violation. Because the running policy is valid and the field team can see it applied, the gap is easy to miss during a change review; the failure is silent rather than erroring, and it typically surfaces only during a security assessment, a network trace, or an incident investigation.

Diagnosis

Confirm the gap using read-only commands before making any change. First list every NetworkPolicy in the namespace and inspect each selector and policy type.

Diagnostic Commands

Run the following read-only checks in the affected namespace.

Correction

The fix is to add an explicit default-deny NetworkPolicy that selects all pods in the namespace with an empty podSelector and no ingress or egress rules, then layer the existing allow-specific policy on top. Apply the default-deny policy first in a non-production namespace, confirm baseline behaviour, then apply it to the target namespace with a defined rollback path.

Validation

Validation succeeds only when explicitly unselected traffic is provably blocked and explicitly allowed traffic still succeeds after the default-deny policy is in place. Test both the negative case (traffic that should now be denied) and the positive case (traffic that must remain permitted) from a temporary test pod, and capture the observed connection results as evidence.

Rollback

Rollback removes the newly applied default-deny policy and returns the namespace to its prior state within one command, since no existing workload configuration is altered by this change.

Prevention

Treat default-deny as the required first policy object in every namespace that uses NetworkPolicy, applied before any allow-specific rule, and enforce this via a namespace admission check or a cluster policy engine (for example, an OPA Gatekeeper or Kyverno constraint) that flags namespaces containing allow-only policies with no matching default-deny object. Include a NetworkPolicy review step in namespace-provisioning checklists, and re-verify policy coverage whenever new workloads are labelled or relabelled, since label changes can silently move a pod out of an existing selector’s scope.