Secure Your Kubernetes Application With Network Policies

By Javier Salmeron
  • kubernetes
  • helm
  • network
  • production
  • security

Introduction

This guide walks you through the basic Kubernetes network policy operations. First you are introduced to the Kubernetes network policies and network plugins. Then you apply these concepts to a multi-tier WordPress installation in kubeadm by completing the following steps:

  • Install a Network plugin.
  • Deploy a Wordpress Helm chart.
  • Apply two network policies for securing the WordPress deployment.

At the end of this guide, you should be able to install a Kubernetes network plugin and apply network policies in your cluster. The examples described in this guide were tested in kubeadm, but they can be applied to any Kubernetes cluster.

By default, all pods in a Kubernetes cluster can communicate freely with each other without any issues. In many environments, you can isolate the services running in pods from each other by applying network restrictions. For example, the following can improve your cluster's security:

  • Only allow traffic between pods that form part of the same application. For example, in a frontend-backend application, only allow communication to the backend from frontend pods.
  • Isolate pod traffic in namespaces. That is, a pod can only communicate with pods that belong to the same namespace.

This guide shows you how you can use the Kubernetes network policies to apply these kinds of restrictions. These restrictions can be combined with pod security policies which are explained in this guide.

Assumptions and prerequisites

This guide makes the following assumptions:

Network policies in Kubernetes

A network policy is a set of network traffic rules applied to a given group of pods in a Kubernetes cluster. Just like every element in Kubernetes, it is modeled using an API Resource: NetworkPolicy. The following describes the broad structure of a network policy:

  • The metadata section of the policy specifies its name.

  • The spec section of the policy outlines the key criteria a pod must fulfil in order to be allowed to run.

    Here is a brief description of the main options available (you can find more details in the official Kubernetes API Reference):

    • podSelector: if the conditions defined in the next element apply, the podSelector establishes which pods the network can accept traffic from (destination pods from now on). Pods can be specified using the following criteria:

      • namespaceSelector: a pod belongs to a given namespace.
      • labelSelector: a pod contains a given label.

    • Network Policy Ingress Rules (ingress): establishes a set of allowed traffic rules. You can specify:

      • from (origin pods): specifies which pods are allowed to access the previously specified destination pods. Just like with destination pods, these origin pods can be specified using NamespaceSelectors and LabelSelectors.
      • ports (allowed ports): specifies which destination pod's ports can be accessed by the origin pods.

You can find an example of what this looks like in the Kubernetes official documentation.

Kubernetes network plugins

In order to implement network policies in your cluster, you must use a compatible container network plugin.

In a usable Kubernetes cluster, pods must be able to communicate between themselves, with services and outside the cluster. Kubernetes is flexible enough (thanks to the use of the Container Networking Interface), or CNI) to allow the administrator to choose between numerous container network technologies (known as CNI plugins). Each one has its own properties and advantages (it is out of the scope of this guide to go through all of them), but not all of them are compatible with the Kubernetes network policies. The following are examples of compatible technologies:

You can find more information on Kubernetes networking in Kubernetes official documentation.

Installing a network plugin in kubeadm

To use the network policies, you must install a network plugin in kubeadm . You can choose among any of the ones detailed in the previous section. For this guide, we will use the Calico plugin.

  • Install the Calico CNI plugin.
kubectl apply -f https://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml

Use case: WordPress installation

In this example, you will add the following network policies:

  • Restrict all traffic between pods.
  • Allow only traffic from Wordpress to MariaDB through port 3306 in a WordPress+MariaDB installation.Crea

Step 1: Deploy a WordPress + MariaDB installation using Helm

  • If you do not have helm installed, install Helm v3.x using the following guide.

  • Deploy a WordPress Helm chart. We will use the name np-test so we know that the WordPress pod will have the app: np-test-wordpress label and the MariaDB pod will have the app: np-test-mariadb label.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install np-test bitnami/wordpress

Step 2: Restrict traffic between pods

  • Create a policy-deny-all.yaml using the content below. In this yaml file you are creating a network rule with an empty PodSelector, which is equal to a wildcard. As there is no ingress section, no traffic is allowed. This means that, unless there are other network rules applied, no pod can communicate with any other pod.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
  • Create the network policy using the kubectl create command:
kubectl create -f policy-deny-all.yaml
  • After some time, check that the WordPress pod crashes because it cannot connect to the MariaDB pod. This is expected as we restricted traffic between all pods.

Step 3: Allow traffic only from the WordPress pod to the MariaDB pod

Now that we have restricted all network traffic between pods, we create an additional policy that allows WordPress to connect to the MariaDB service. We can create additional network rules such as this to ensure that we only allow traffic where needed.

  • Create a policy-wordpress-mariadb.yaml with the content below. In this yaml file you are creating a network rule with the MariaDB pods (i.e. all pods with label app: np-test-mariadb) as destination pods. In the network policy ingress rules, you set the WordPress pods (that is, all pods with label app: np-test-wordpress) as the origin pods, and 3306 as the allowed port.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-frontend-allow
spec:
  podSelector:
    matchLabels:
      app: np-test-mariadb
  ingress:
    - from:
      - podSelector:
          matchLabels:
            app: np-test-wordpress
      ports:
        - protocol: TCP
          port: 3306
  • Create the network policy using the kubectl create command:
kubectl create -f policy-wordpress-mariadb.yaml
  • Check that the WordPress pod now works without issues.
kubectl get pods

NAME                                   READY     STATUS    RESTARTS   AGE
np-test-mariadb-2450482308-4sw28     1/1       Running   0          2d
np-test-wordpress-2742268951-kg4km   1/1       Running   7          2d

Useful links

Now you are able to perform basic network policy operationIn this guide we walked you through the concept of network policies and network plugins. Thanks to that, you were able to secure a multi-tier application (Wordpress+MariaDB Helm chart) by isolating them from the rest of the cluster pods. This is a first step in the numerous applications where network policies and network plugins offer to your cluster. For more information, see the following links: