Review Kubernetes NetworkPolicy as combined permissions at both endpoints

One restrictive-looking policy does not cancel another policy’s allowed traffic.

Source facts

Kubernetes NetworkPolicies are additive: the allowed connections from all applicable ingress or egress policies combine. For a connection between isolated Pods, the source’s egress and destination’s ingress must both allow it. Enforcement requires a network plugin that supports NetworkPolicy. A policy object’s existence therefore is not independent proof that traffic restrictions are active.

Source: Kubernetes documentation — Network Policies.

Applicability

Review the documented IP/port-level Kubernetes NetworkPolicy model and the plugin needed to enforce it.

DSE recommendation

DSE recommends mapping a connection from its initiating Pod to its destination and reviewing every matching policy at both ends. Record required DNS and external-service access alongside application ports. Treat a broad namespace or Pod selector as a real expansion of effective permission, even if a narrower policy remains present. Verify the installed network implementation before presenting a policy as an isolation control. Keep expected denied paths in the change record so testing does not stop after confirming the application can still communicate.

Verification

In an approved test namespace, exercise one allowed flow and one explicitly unintended flow. Add a temporary policy that broadens the allow set and observe the combined result. Remove the test configuration and confirm that both ingress and egress behavior match the final design. Retain the complete matching policy set and both Pod label sets beside the test result. Have the network owner account for an unexpectedly allowed connection before considering a narrower-looking policy sufficient.

Official reference

Kubernetes documentation — Network Policies. Reviewed October 20, 2026.