Controlling and filtering traffic when containerizing a workload within Kubernetes Pods is just as crucial as a firewall in a more traditional network setup. The difference is that, in this scenario, those capabilities are provided by the Kubernetes NetworkPolicy API.

This article will explore Kubernetes NetworkPolicy by creating an example network policy and examining its core parameters. Then, we’ll look at some common NetworkPolicy use cases and learn how to monitor them using kubectl. Finally, we’ll discover how to implement Container Network Interface (CNI) using third-party Kubernetes extensions.

Why you shouldn’t shy away from Kubernetes network policies

Implementing network policies is critical to operating a Kubernetes environment. Without a configured network policy, all Pods within a cluster can communicate with each other by default. So, when our Pod contains sensitive data, such as a backend database holding confidential information, we must ensure that only certain frontend Pods can connect to it. 

Alternatively, we can isolate network traffic across Pods in a development environment from those running in a production environment. Without network policies, all traffic moves freely to and from all points in the network. 

Fortunately, configuring Kubernetes NetworkPolicy is a simple, effective, and holistic means for ensuring our network traffic flows only as intended.

Defining Kubernetes network policies

Let’s take a look at a sample NetworkPolicy. Consider a sample workload with a WordPress front end and MySQL database back end, running a collection of Pods containing both web and database services, all deployed within the Kubernetes default namespace. The company’s security protocols mandate that we isolate network traffic for specific workloads and allow the minimum necessary incoming and outgoing traffic to use these workloads. 

This strategy involves the following conditions:

• Blocking the default Kubernetes behavior that allows all traffic.
• Ensuring that only Pods labeled wordpress in the default namespace can communicate with one another.
• Allowing incoming (ingress) connectivity from public internet on ports 80/443 and the 172.16.0.0 IP range.
• Only allowing the Pods labeled wordpress to connect to the MySQL database Pods on port 3306.
• Always allowing connectivity to the Kubernetes DNS service (port 53).
• Blocking all outgoing connectivity outside of the cluster.

The network diagram below illustrates how these rules might look.

For this example, we can either distribute the network policies across the policy definition files or combine all policies into a single YAML manifest file. Since our example uses one workload (webapp), using one rulebase definition file makes sense. However, since this example holds several ingress and egress connections, we could alternatively create individual configuration files for each connection within the cluster.

Let’s walk through several of the parameters used above to understand how they relate to the configuration and affect network traffic behavior.

API and metadata

In the first line of the YAML file below, we specify the networking API (networking.k8s.io) and its version (v1). We also define the kind of YAML file as NetworkPolicy, informing the Kubernetes API controller that we’re configuring network policies. The name and namespace items in the metadata section contain the name we give this ruleset and the namespace to which it’s linked. 

apiVersion: networking.k8s.io/v1
kind: Net