NetworkPolicy Tutorial

Welcome! 👋 This tutorial helps you get started with Kubernetes NetworkPolicy.

What is Kubernetes NetworkPolicy?

NetworkPolicy is a standardized Kubernetes object to control the allowed network traffic patterns between Kubernetes pods and namespaces as well as any traffic entering or leaving the cluster. However, Kubernetes itself does not provide an implementation of NetworkPolicy, it is typically provided by the [CNI plugin]. If no NetworkPolicy is loaded, all communication is allowed which is clearly violating least-privilege and zero-trust security privileges. For more information on the concept, see Network Policies in the Kubernetes documentation.

What will you learn in this Tutorial?

In this tutorial, we will cover the following topics:

• Fundamentals:
  • Kubernetes 101
  • Default Allow & Default Deny
  • Ingress & Egress
• Ingress Controls
  • Putting a pod into ingress default deny
  • Allow pod to pod connectivty (ingress)
  • Allow everything within a namespace (ingress)
  • Allow across namespaces
• Egress Controls
  • Putting a pod into egress default deny
  • Allow pod to pod connectivity
  • Allow Kubernetes DNS (across namespaces)

Getting Started: Create a Kubernetes Cluster with a CNI

In order to enforce Kubernetes NetworkPolicies, your cluster must be running with a CNI that is capable of enforcing NetworkPolicies. Multiple options exist, for this tutorial we will be using Cilium as it provides nice visibility tooling to help us illustrate things as we go along.

If you already have a Kubernets cluster with an appropriate CNI plugin installed, then skip the following steps.

Create a Cluster

GKE

export CLUSTER_NAME=test-$(whoami)-$RANDOM
export CLUSTER_ZONE=us-west2-a
gcloud container clusters create $CLUSTER_NAME --image-type COS --num-nodes 2 --machine-type n1-standard-4 --zone $CLUSTER_ZONE
gcloud container clusters get-credentials $CLUSTER_NAME --zone $CLUSTER_ZONE

minikube

minikube start --network-plugin=cni

Install Cilium

Note: You can install and use any CNI that supports NetworkPolicy to complete this tutorial. Skip this section if already have a CNI installed with NetworkPolicy.

Darwin

curl -LO https://github.com/cilium/cilium-cli/releases/download/v0.4/cilium-darwin-amd64.tar.gz
tar xzvf cilium-darwin-amd64.tar.gz
sudo mv cilium /usr/local/bin
cilium install
cilium status

Linux

curl -LO https://github.com/cilium/cilium-cli/releases/download/v0.4/cilium-linux-amd64.tar.gz
tar xzvf cilium-linux-amd64.tar.gz
sudo mv cilium /usr/local/bin
cilium install
cilium status

Enable Hubble (Optional)

If you want, you can enable Hubble to get a fully distributed network monitor that will show you every forwarding and drop decision in your cluster.

1. Install Hubble

2. Enable Hubble in Cilium:

    cilium hubble enable
   

3. Add a port forward with kubectl to expose Hubble. You can obviously also expose a LoadBalancer service if you want but for the simplicity of this tutorial, a port-forward is the simplest solution:

    kubectl port-forward -n kube-system deployment/hubble-relay 4245:4245&
   

4. Run hubble observe to start observing all network traffic in the default namespace:

    hubble observe --server localhost:4245 -f -n default
   

Fundamentals

NetworkPolicy is a standardized Kubernetes object to control the allowed network traffic patterns between Kubernetes pods and namespaces as well as any traffic in and out of a cluster. However, Kubernetes itself does not provide an implementation of NetworkPolicy, it is typically provided by the [CNI plugin]. If no NetworkPolicy is loaded, all communication is allowed which is clearly violating least-privilege and zero-trust security privileges. It is thus in the best interest of any Kubernetes cluster operator to understand and use the concept of NetworkPolicy.

When referring to NetworkPolicy more broadly, users may refer to both the standard Kubernetes NetworkPolicy as well as the extended version with additional capabilities specific to the selected [CNI plugin], e.g. [CiliumNetworkPolicy]. These extended versions are typically implemented as Custom Resources. In the initial chapters of this tutorial, we will focus on Kubernetes NetworkPolicy and then dive into some of the extensions to understand benefits and tradeoffs.

101 - Namespaces, Pods, & Services

In order to understand NetworkPolicy, you need to understand the basics of Kubernetes objects. This is a quick 101 of the Kubernetes objects that are relevant for NetworkPolicy. If you are already familiar with Kubernetes objects, feel free to skip this section. If are looking for a more detailed introduced, refer to the Kubernetes documentation Working with Kubernetes Objects.

Namespaces

A namespace groups Kubernetes objects into a specific context. If you want, you can consider it a virtual cluster. Namespaces allow to share a cluster among multiple tenants. In the context of NetworkPolicy, it is most common to define the scope of a NetworkPolicy to only apply within a particular namespace and specifically handle any cross-namespace communication. More on this later.

Pods

Pods are the smallest deployable unit of an application that you can create and manage. Pods are typically created via a higher-level object such as a Deployments, DaemonSets, Jobs, StatefulSets, etc. and are deployed directly into a particular Namespace. A pod consist of one or more application containers which all share the same storage and network resources and always run on the same host. If your application is scalable and deployed with multiple replicas then each replica is deployed as an individual pod. Pods can be assigned a set of Labels. These labels allow to select any number of pods and treat them in artbirary groups using Selectors. In the context of NetworkPolicy, a policy is applied to one or more pods by selecting pod labels in the NetworkPolicy. The policy is then applied to all application containers of any pod that matches the label selector.

Services

Applications running as pods are made available to other pods and to external clients using services. A service makes a set of pods available using an internal or external IP address and assigns a stable DNS name to this IP to allow for the discovery of the service by other pods. In the context of NetworkPolicy, services typically play a minor role as policies are applied to pods directly but use of services can influence how NetworkPolicy has to be defined.

If you want to deepen your understanding of Kubernets objects before continuing, feel free to dive into the Kubernetes Concepts chapters of the Kubernetes documentation.

Default Allow & Default Deny

In the absence of any NetworkPolicy, the default behavior of a Kubernetes cluster is to allow everything on the network. It is your responsibility as an operator of a Kubernetes cluster to create NetworkPolicy objects to change the default allow setting to default deny and the explicitely allow all required traffic paterns.

If your Kubernetes cluster is already running many applications, this may appear difficult as changing from a default allow to a default deny security model in a single step may appear challenging. Fortunately, NetworkPolicy allows to change the default deny setting for individual groups of pods or individual namespaces so you can start locking down the most important applications first and improve your security posture step by step.

Before we now create our first NetworkPolicy, we need to understand one more fundamental concept:

Ingress & Egress

Ingress and egress are terms used in networking to describe traffic direction. Ingress refers to network traffic that is transmitted into a Kubernetes pod and egress is refers to network traffic that is emmited by a pod.

The default deny setting of a pod can be control for each traffic direction separately, i.e., you can initially deny all traffic into a pod and start allowing individual traffic patterns while still allowing all network traffic leaving a pod.

Ingress Controls

We are now ready to create our first NetworkPolicy to put a set of pods into default deny and then allow a set of network traffic.

Create Demo App

Create the following demo-app in your Kubernetes cluster. The examples will assume that you deploy the demo app into the default namespace but you can of course use any namespace and adjust the examples accordingly.

kubectl create -f tutorial/demo-app.yaml

Validate that you have frontend and