Network Policy: KCSA practice questions

A NetworkPolicy controls traffic at the IP address and port level (OSI layers 3 and 4) for TCP, UDP and SCTP, between Pods and between Pods and the outside world. It is an application-centric object in the networking.k8s.io API group. The peers a Pod may talk to are expressed in three ways: other Pods chosen by label, namespaces chosen by label, and IP blocks written as CIDR ranges. Labels are therefore the backbone of network segmentation; a policy can only target what it can select, which is why commands such as kubectl label pod matter here.

Without any policy, Pods are non-isolated: all inbound and all outbound connections are allowed. A Pod becomes isolated for ingress when at least one NetworkPolicy selects it and lists Ingress in its policyTypes, and isolated for egress when a selecting policy lists Egress. Once isolated in a direction, only connections explicitly allowed by some applicable policy are permitted, and reply traffic for those connections is allowed implicitly. Policies never conflict: they are additive, so the allowed set is the union of all applicable rules and evaluation order does not matter. For a connection between two Pods to succeed, the egress side of the source and the ingress side of the destination must both allow it.

The spec has a few fields to know precisely. podSelector chooses the Pods the policy applies to, and an empty podSelector selects every Pod in the namespace. policyTypes lists Ingress, Egress or both; if it is omitted, Ingress is always assumed and Egress is added only when the policy has egress rules. ingress rules use from, egress rules use to, and both combine peers with ports. Inside a peer, namespaceSelector alone admits all Pods in matching namespaces, while namespaceSelector and podSelector in the same element admit only matching Pods in matching namespaces, so YAML indentation changes the meaning. A default deny for egress is a policy with podSelector {} and policyTypes Egress and no egress rules; note that it also blocks DNS unless another policy allows traffic to the cluster DNS service. Leaving egress unrestricted means a compromised Pod can open connections to any destination.

Enforcement depends on the network plugin. Creating a NetworkPolicy in a cluster whose plugin does not implement it has no effect at all, which is the usual reason a policy seems to be ignored. The Kubernetes documentation lists Antrea, Calico, Cilium and Kube-router as providers. The API also has deliberate limits: it cannot handle TLS, cannot target Services by name, cannot log blocked connections and has no explicit deny rule. The documentation points to service meshes, ingress controllers and operating system components for those needs.