Network Policy

A NetworkPolicy is a namespaced Kubernetes object that controls traffic to and from selected pods at the IP address and port level (layers 3 and 4), for TCP, UDP and SCTP.

How it works

By default pods are non-isolated and accept all traffic. A pod becomes isolated for ingress or egress once a policy selects it and lists that direction in policyTypes. After that, only traffic allowed by the policies is permitted. Policies are additive: they only allow, never deny, and the allowed set is the union of all matching policies. A connection needs both sides to permit it, the source’s egress and the destination’s ingress.

Rules select peers using podSelector, namespaceSelector and ipBlock. An empty podSelector selects every pod in the namespace.

Enforcement is done by the network plugin, not the API server. Creating a policy on a cluster whose plugin does not support it has no effect. On EKS, the Amazon VPC CNI can enforce policies when network policy support is enabled on the add-on, and it has version and node kernel prerequisites. Other CNIs such as Calico and Cilium also enforce them.

A practical example

A default deny baseline for a namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

You then add policies that allow specific flows, such as the frontend reaching the API on its port, and DNS egress to CoreDNS.

Common mistakes

• Writing policies on a cluster whose CNI does not enforce them, then assuming protection.
• Denying egress without allowing DNS, which breaks name resolution.
• Misreading selectors: entries in the same list item combine with AND, while separate items combine with OR.
• Forgetting that policies are namespaced and need a namespaceSelector for cross-namespace flows.
• Not testing, so legitimate traffic is blocked.

When to use it and when not to

Use NetworkPolicies to limit lateral movement and to separate tenants or tiers sharing a cluster. They are layer 3 and 4 only, so they do not inspect HTTP paths or verify identity. For that, consider a service mesh. See also the Kubernetes network policy implementation service.

See also

• RBAC
• Kubernetes
• EKS
• Namespace
• EKS network policies and security groups