Kubernetes NetworkPolicy Builder

A NetworkPolicy is a Kubernetes resource that defines how pods communicate with each other and with external endpoints. By default, all pods can communicate freely — a NetworkPolicy selects pods via labelSelector and restricts which traffic is allowed. Crucially, NetworkPolicy requires a CNI plugin that enforces it: Calico, Cilium, Weave Net, or Antrea. Flannel does NOT enforce NetworkPolicy. Creating a policy with an empty podSelector {} applies it to all pods in the namespace, immediately defaulting to deny-all.

Ingress rules control inbound traffic — which sources can send traffic TO the selected pods. Egress rules control outbound traffic — where the selected pods can SEND traffic. If you specify an ingress block, only the listed sources are allowed; all other inbound traffic is denied. Same for egress. If you omit the ingress or egress block entirely, it is not restricted by this policy. To create a default deny-all, create a NetworkPolicy that selects all pods but has empty ingress: [] and egress: [] arrays.

In a NetworkPolicy from/to rule, namespaceSelector selects entire namespaces (all pods in matching namespaces), podSelector selects pods within the same namespace as the policy, and you can combine them. If you put BOTH in the same rule object (using AND logic): { namespaceSelector: {...}, podSelector: {...} } — it selects pods matching podSelector WITHIN namespaces matching namespaceSelector. If you use separate list items (OR logic), each is an independent source. This AND vs OR distinction is critical and a common source of bugs.

DNS uses UDP and TCP port 53. If you create a deny-all egress policy, pods lose DNS resolution. Always add an explicit egress rule allowing port 53 to your cluster's DNS service: { ports: [{ port: 53, protocol: UDP }, { port: 53, protocol: TCP }], to: [{ namespaceSelector: { matchLabels: { kubernetes.io/metadata.name: kube-system } } }] }. Without this, pods cannot resolve service names, breaking all service discovery. This is the most common mistake when implementing egress policies.

ipBlock allows specifying a CIDR range as a traffic source or destination. Use it for: allowing traffic from external load balancers or specific IP ranges (office IPs, VPN CIDRs), allowing egress to external APIs (e.g. 0.0.0.0/0 except internal RFC1918 ranges), or blocking access to cloud metadata endpoints (169.254.0.0/16 via except). The except field within ipBlock lets you exclude sub-ranges from a broader CIDR. ipBlock cannot reference pod or namespace labels — use podSelector/namespaceSelector for internal cluster traffic.