Kubernetes NetworkPolicy objects can exist in the API without actually restricting any traffic, creating a false sense of security that only surfaces during penetration tests. The original Russian article from OTUS details five critical mistakes that produce exactly this outcome: policies are visible via kubectl get networkpolicy yet traffic flows freely.
CNI Plugin Does Not Support NetworkPolicy
Kubernetes stores NetworkPolicy objects but relies on the Container Network Interface plugin for enforcement. Plugins such as Calico, Cilium, and Weave Net implement them, while plain Flannel and kubenet do not. Administrators can confirm the plugin by checking pods in the kube-system namespace, yet the most reliable test applies a deny-all policy in a test namespace and attempts cross-namespace connectivity with tools like nicolaka/netshoot.
Default-Deny Egress Blocks DNS Resolution
Applying an egress deny-all rule immediately breaks name resolution because queries to CoreDNS on port 53 are also blocked. Applications report UnknownHostException or timeouts rather than access denied errors, leading teams to investigate the DNS service instead of the policy. The recommended fix adds a separate policy allowing UDP and TCP traffic to the kube-dns pods in the kube-system namespace.
Single Dash Creates Cluster-Wide Access
A misplaced dash in the YAML turns an AND condition into an OR condition. The correct structure places namespaceSelector and podSelector under the same list item so that only pods matching both labels are permitted. When separated by an extra dash, any pod bearing the label app: api from any namespace gains access, silently expanding the attack surface.
namespaceSelector Matches Labels, Not Namespace Names
The selector matchLabels: name: monitoring looks for a label on the namespace object, not its name. Most namespaces only carry the automatic label kubernetes.io/metadata.name. Administrators must either use this built-in label or manually apply custom labels, understanding that custom labels can be forgotten on newly created namespaces.
Confusion Between Protected Pods and Allowed Sources
The top-level podSelector defines which pods the policy protects, while selectors inside from or to blocks define allowed peers. Swapping these produces a policy with an empty from: [] list that permits traffic from everywhere. An empty ingress list without any rules denies all ingress, whereas a rule containing an empty source list allows all sources.
Additional coverage gaps remain even with correct policies: pods using hostNetwork: true bypass the CNI, intra-pod localhost traffic between containers is uncontrolled, and response traffic for established connections is automatically permitted. The article advises starting with traffic tests, rolling out default-deny together with DNS allowances, using policy audit modes in Calico and Cilium, and keeping a single-command rollback ready.
