Kubernetes NetworkPolicy: isolate and test traffic

In a Kubernetes cluster, a pod that is not selected by any NetworkPolicy is allowed to communicate both in and out of the cluster by default. This default behavior can pose a security risk, as demonstrated by a container in a staging namespace being able to query the production database. To mitigate this risk, a Kubernetes NetworkPolicy can be used to restrict traffic flow.

A NetworkPolicy is created by defining a podSelector to select the pods it applies to, and specifying the policyTypes (ingress or egress) and rules for allowed connections. The podSelector is set to {} to apply the policy to all pods in the namespace. The rules are defined by pods, namespaces, IP ranges, and optional ports, with optional ingress and egress rules.

When creating a NetworkPolicy, it is important to follow best practices to avoid unintended consequences. The policy should only grant the necessary permissions and avoid the use of deny rules, as these are not supported. Instead, the focus should be on granting only the required permissions. Additionally, the policy should be tested thoroughly to ensure that it is functioning as intended and that no unintended connections are allowed.

One common mistake is using a full egress deny, which can also cut off name resolution for applications. To avoid this issue, a second policy can be added to allow egress to the cluster DNS. It is important to note that the NetworkPolicy does not provide logging of network security events and relies on the CNI (Container Network Interface) for observability.

When implementing NetworkPolicies, it is recommended to follow a rollout order, starting with a default-deny-all policy for each namespace, followed by specific DNS rules. Each policy should be named after its purpose and versioned in Git. Finally, each rule should have both a passing and failing test to ensure that it is functioning correctly.