Search This Blog

Saturday, June 15, 2024

Network policy in kubernetes using calico

Introduction to the problem

All pods in Kubernetes can reach each other. For example, the frontend can reach the backend and the backend can reach the database. That is expected and normal. But this openness can make problems like:

  • The frontend can reach the database!
  • Applications from different namespaces can talk to each other!
  • This means, if a container gets hacked, it will have access to all the containers!

That would be a security issue. We want to apply the principle of least privilege from The Zero Trust Network model: each pod should get access to the strict minimum and only the pods it is supposed to access to. If it doesn't need access to other pods, there should be a rule to deny that possible access.

In this workshop, we will learn how to setup network policies in Kubernetes to:

  • Deny pods to reach pods within all other namespaces.
  • Deny pods to reach any pods except specific ones.

NetworkPolicy is defined in Kubernetes API as a specification. But it is not implemented. It is up to us to choose the implementation. There are multiple solutions available, like Calico, Azure Network Policy, Weave, Cilium, Romana, Kube-router…

This workshop is also available as a video on youtube:

 

calico.png

 

We need to choose one for this demo, so we'll go for Calico as it is one of the widely used. But we can still choose another implementation and the demo still applicable.

Then we need to have a Kubernetes cluster. We can choose between Minikube, GKE, EKS, PKS and all things xKy. We'll choose here AKS (Azure Kubernetes Service).

In AKS, we can choose between Calico and Azure Network Policy. Until now, Calico could be enabled only on new clusters, not existing ones. Follow the following instructions to create a new AKS cluster and enable Calico.

1. Enabling Calico in AKS

  • Enabling Calico from the Azure Portal

When we create a new AKS cluster in the Azure Portal, under the Networking tab, we'll have the option to select Calico.

calico-azure.png

  • Enabling Calico from the Azure CLI: az

From the az command line, when we create a new AKS cluster, we can add the parameter –network-policy.

 

 

 az aks create --resource-group <RG> --name <NAME> --network-policy calico 

 

 

  • Enabling Calico from Terraform

In Terraform, we can add the network_policy with value set to "calico" inside "azurerm_kubernetes_cluster" as described in the following link:

https://www.terraform.io/docs/providers/azurerm/r/kubernetes_cluster.html#network_policy

 

 

  network_profile {      network_plugin = "kubenet"      network_policy = "calico"    }

 

 

In the following scenarios, we'll define a network policy and we'll test how it works. So, lets create a Nginx Pod that will act as the backend for the application. Then we'll simulate an Alpine Pod that acts as the frontend who tries to reach the backend.

First, let's create a namespace with labels. Create a new file with the following content:

 

 

# 1-namespace-development.yaml  apiVersion: v1  kind: Namespace  metadata:    name: development    labels:      purpose: development

 

 

Then create the namespace with the following command:

 

 

 kubectl create -f 1-namespace-development.yaml

 

 

After that, create the backend Nginx Pod with a Service with the following command:

 

 

kubectl run backend --image=nginx --labels app=webapp,role=backend --namespace development --expose --port 80 --generator=run-pod/v1

 

 

This command will generate a Pod and Service like the following config here.

Scenario 1: Deny inbound traffic from all Pods

Let's create a policy to deny access to our backend Pod.

 

 

# 1-network-policy-deny-all.yaml  kind: NetworkPolicy  apiVersion: networking.k8s.io/v1  metadata:    name: backend-policy    namespace: development  spec:    podSelector:      match
========

No comments:

Post a Comment