Kubernetes relies on a CNI plugin to provision and configure networking for Pods. The Container Network Interface (CNI) specification defines how these plugins integrate with Kubernetes. This is the main task that the CNI is responsible for, and without a CNI, networking will not work in the Kubernetes cluster.

As time went on, however, Kubernetes advanced in features and functionalities, and so did the CNI. Today, modern CNI plugins provide far more functionality than simply attaching network interfaces.

One of the features the CNI provides is NetworkPolicies. NetworkPolicies are the first step in securing your microservices from unauthorized access. NetworkPolicies are one of the foundational building blocks of a zero-trust Kubernetes environment. They secure your microservice architecture from unauthorized access by disallowing unrequired network traffic.

The best thing about NetworkPolicies is that they are cheap and easy to deploy. They come with the CNI (depending on which one you use), so you don’t have to install anything extra. Defining a NetworkPolicy is the same as with any other resource in Kubernetes. You guessed it, it’s a YAML manifest.

Of course, it depends on which CNI you use. There are quite a few you can choose from, but not every CNI supports NetworkPolicies. Popular CNIs that do support NetworkPolicies are Cilium and Calico. But they all work more or less the same. You define the traffic you want to allow in the manifest, as we will soon see.

In the manifest, you can specify which Pods may talk to which endpoints. This brings me to the functionality of NetworkPolicies. The benefit they bring to the table is huge, as they control which Pods can talk to which Pods.

In other words, without NetworkPolicies, as soon as you expose a Pod with an IP address, every other Pod in the cluster can call that Pod’s endpoints. NetworkPolicies restrict that access. Once a Pod is selected by an ingress NetworkPolicy, any traffic not explicitly allowed by that policy is denied. The Pods that are able to call the endpoint are specified within the selector, which maps to the label of the Pod with access. The concept is similar to mapping a Service to a Deployment.

In the following example, ingress traffic to endpoints in the namespace: production with label color: red is allowed, only if it comes from a Pod in the same namespace with color: blue, on port 6379.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-tcp-6379
  namespace: production
spec:
  selector: color == 'red'
  ingress:
    - action: Allow
      protocol: TCP
      source:
        selector: color == 'blue'
      destination:
        ports:
          - 6379

But why are NetworkPolicies so important? The cluster is not accessible from the public internet anyway, so why even bother?

The reason is that implementing NetworkPolicies is a best practice. It is like brushing your teeth in the morning even if you are not going out. You could not brush your teeth at all, and it would not make a difference. You already brushed them last night, so why even bother, right?

But where does it end? What if the next thing we decide is redundant is washing yourself every second day, or changing your clothes… the next thing you know, you live like somebody from the Stone Age.

NetworkPolicies are a lot like brushing teeth. They are the first step to securing your cluster, and in a way, the most important one. Implementing NetworkPolicies ensures you do not cut corners along the way to designing a secure and highly available Kubernetes cluster.