Network Policies

Before any NetworkPolicy selects a Pod, that Pod is non-isolated: every other Pod, on any namespace, and every external address, can open a connection to it on any port, and it can open a connection to anything in turn. There is no implicit firewall to opt out of — Kubernetes ships with an entirely flat, allow-all Pod network, and isolation is something a NetworkPolicy adds, never something a Pod starts with and a policy relaxes. That matters for reading the rules below correctly: a NetworkPolicy is not a stateful firewall rule with a default DROP, it is closer to a label selector that switches a Pod from "reachable from everywhere" to "reachable only from what an ingress rule names" — the moment spec.podSelector in any NetworkPolicy in the namespace matches a Pod for a given direction (Ingress or Egress), that Pod becomes isolated for that direction, and every rule from every matching policy is then combined additively: if any policy allows a connection, it is allowed, regardless of how many other policies stay silent about it.

Source: Kubernetes Docs — Network Policies.

Source: Kubernetes Docs — Network Policies.

Source: Kubernetes Docs — Network Policies.

A NetworkPolicy is enforced from both ends of a connection at once: catalog-api-to-postgres above only grants ingress into postgres; catalog-api still needs no egress policy of its own to reach it, because it remains non-isolated for egress until some other policy selects them (the allow-DNS-egress policy below is the first thing in Bookshelf that does). Traffic to and from the node a Pod runs on is always allowed regardless of any policy, a Pod’s reply to a connection it initiated is always allowed (NetworkPolicy has no notion of "half-open" a legitimate response can violate), and a Pod can never be blocked from reaching itself.

The single most common NetworkPolicy in any real cluster is not one that allows a specific flow, but one that switches a whole namespace from the flat, open default to "nothing, unless another policy says otherwise" — written with an empty podSelector and no rules at all:

Source: Kubernetes Docs — Default Deny All Ingress and All Egress Traffic.

podSelector: {} matches every Pod in bookshelf; an empty ingress list under policyTypes: [Ingress] means "no rule allows anything", so every selected Pod becomes fully isolated for ingress and egress alike, with no traffic getting through until a more specific policy — catalog-api-to-postgres above, or the allow-DNS-egress policy below — opens a named hole back up. Applying this first, before any allow policy exists, is the standard way to move a namespace from implicit-allow to explicit-allow without a gap where everything is briefly reachable; applying it after other allow policies already exist changes nothing for the flows those policies already permit, since NetworkPolicies compose additively regardless of the order they were created in.

A default-deny-all policy has one immediate, easy-to-miss consequence: it also blocks the DNS lookups every Pod needs before it can reach anything by name, including the CoreDNS lookups DNS and Service Discovery describes for postgres.bookshelf.svc.cluster.local itself. An egress rule that allows only DNS, applied to every Pod alongside the default-deny policy, is the standard fix:

Source: Kubernetes Docs — Network Policies.

Both UDP/53 and TCP/53 are listed because CoreDNS answers most lookups over UDP but falls back to TCP for answers too large for a single UDP datagram; the namespaceSelector + podSelector pair targets CoreDNS’s own Pods specifically (labeled k8s-app: kube-dns in kube-system on a stock kubeadm or kind cluster) rather than opening egress to the whole kube-system namespace. kubernetes.io/metadata.name, the label every namespace carries automatically since Kubernetes 1.22 with its own name as the value, is what makes a namespaceSelector usable against a specific namespace at all without that namespace having to be labelled by hand first.

Putting the pieces together, Bookshelf's bookshelf namespace ends up with three NetworkPolicies: the default-deny-all above, the allow-DNS-egress above, and catalog-api-to-postgres from the top of this page, narrowing PostgreSQL’s reachable clients down to catalog-api alone. Two details finish the picture:

Not every peer a policy needs to reference is a Pod inside the cluster. ipBlock names a raw CIDR range instead of a label selector, which is how a policy allows or restricts traffic to something outside the Pod network entirely — a selectorless Service pointing at a legacy database reachable only by IP, or a partner API Bookshelf calls out to on a known address range:

Source: Kubernetes Docs — Network Policies.

except carves a narrower range back out of the allowed block — here, a /28 reserved for the partner’s own internal tooling, not notifier’s traffic to reach. `ipBlock addresses are always evaluated against a Pod’s observed source or destination IP, never against a Service’s ClusterIP, since a NetworkPolicy sits below the level a Service’s virtual IP is rewritten at; the deprecated Endpoints API and its EndpointSlice successor (Services) exist to make that distinction moot for selectorless Services targeting Pods, but an external, non-Kubernetes address is exactly where ipBlock is the only option.

A NetworkPolicy object is only ever a request — nothing in the API server itself blocks a packet. Enforcement is entirely the job of the CNI plugin, which must watch NetworkPolicy objects and program the node’s packet filtering (iptables, nftables or an eBPF dataplane) to match. Applying the manifests above to a cluster whose CNI ignores NetworkPolicy silently does nothing: kubectl get networkpolicy still shows the objects, kubectl describe still shows their rules, and every connection this page describes as blocked keeps working exactly as before.

kind’s default CNI, kindnetd, gained out-of-the-box NetworkPolicy enforcement in kind v0.24.0 (August 2024), built on the sigs.k8s.io/kube-network-policies controller, with a DNS-handling fix following in v0.25.0, so a default kind create cluster on any recent kind release enforces every policy above with no extra installation step. Confirm this on any given cluster rather than taking it on faith, since it depends on which kind version actually created the cluster and whether networking.disableDefaultCNI was set:

The most direct check is the temporary-Pod test below: apply default-deny-all, confirm a Pod that used to succeed now times out, then delete the policy and confirm it succeeds again. If enforcement is genuinely absent — an older kind version, or a cluster created with disableDefaultCNI: true and no NetworkPolicy-capable CNI installed in its place — the standard fallback is to install Calico on the kind node network instead of kindnet, following Calico’s own kind quickstart:

Source: kind Docs — Configuration (disableDefaultCNI) and Calico Docs — Install Calico Networking and Network Policy for Kubernetes. Cilium is a common alternative offering the same NetworkPolicy enforcement plus its own CRDs for L7 and DNS-aware policies; see Cluster Networking, CNI and Service Mesh for a fuller comparison of CNI plugins beyond NetworkPolicy enforcement alone.

NetworkPolicy objects are always namespace-scoped and owned by whoever can create objects in that namespace — there is no cluster-wide policy a platform team can set that an application team’s own namespaced policies cannot override or leave gaps in. The sigs.k8s.io/network-policy-api subproject (a separate CRD-based API, group policy.networking.k8s.io, not part of core Kubernetes) fills that gap with AdminNetworkPolicy and BaselineAdminNetworkPolicy — cluster-scoped policies a platform operator sets, evaluated before (admin tier) or after (baseline tier, as a fallback default) every namespace’s own NetworkPolicy objects. As of this project’s current v1alpha2 iteration, those two resources have been superseded in the API’s own roadmap by a unified ClusterNetworkPolicy resource carrying both an Admin and a Baseline tier in one object; none of this family is part of the core, stable networking.k8s.io/v1 API this page otherwise describes, and support depends entirely on the CNI in use — Calico, Cilium and OVN-Kubernetes each implement some portion of it, kindnet does not. Bookshelf does not need a cluster-scoped policy, so this section stops at naming the mechanism rather than working an example.

Source: Kubernetes SIG Network — Network Policy API.

Every policy above is worth confirming against the live cluster rather than trusting the manifest, since a typo in a label selector fails silently the same way an unenforced CNI does — both look like "nothing happened" from kubectl apply’s point of view. A short-lived, throwaway Pod is the standard tool, created with `--rm so it is deleted the moment the shell session exits:

The --labels flag matters as much as the image: catalog-api-to-postgres’s ingress rule matches on `app.kubernetes.io/name, so a test Pod carrying the wrong label is indistinguishable, from the policy’s point of view, from any other unauthorised Pod, regardless of which real Deployment it is meant to stand in for. Repeating the same check with the default-deny-all and allow-dns-egress policies temporarily deleted (kubectl delete networkpolicy --all -n bookshelf) and confirming every combination now succeeds is a useful sanity check that the failures above came from the policies and not from a Service or DNS problem (Debugging and Troubleshooting covers that failure mode, "NetworkPolicy block", as one row of its failure-state table).

Source: Kubernetes Docs — Network Policies.