Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Improve Your Pods Communication with Network Policies on AKS

  • February 16, 2021
  • 5 min read
Cloud and Virtualization Architect. Florent is specializing in public, hybrid, and private cloud technologies. He is a Microsoft MVP in Cloud and Datacenter Management and an MCSE in Private Cloud.
Cloud and Virtualization Architect. Florent is specializing in public, hybrid, and private cloud technologies. He is a Microsoft MVP in Cloud and Datacenter Management and an MCSE in Private Cloud.


By default, all pods can talk to each other in AKS clusters. Such uncontrolled communication can compromise cybersecurity. So, to avoid these security issues, you can implement network policies, restrict flows between pods, and allow only what you want to allow.

These network rules will be defined, in a YAML file, during the deployment.

In this article, we will speak about Azure Network Policies, but you can also use Calico Network Policies.

How will it work? It’s very simple: it will use Linux IP Tables, to allow and deny between IP of pods.

To start, be sure that you deployed your AKS cluster, with Azure CNI as the network plugin type and with the network policy parameter, with value azure. In my case, I used the following script to deploy the AKS cluster:

StarWInd Networking

It is very important to enable it because after the AKS cluster has been deployed, it will not be possible to activate it.

Traffic between pods

Before starting, deploy a new namespace and a new pod, as backend:

Now, block the traffic to a pod, from everywhere. Apply the following yaml file:

As you can see, the ingress part is empty; that says that everything will be blocked.

Block the traffic to a pod

Run a temporary pod and try to download the index from the backend, with the following command:

Run a temporary pod and try to download the index

Now, we will apply an ingress. Edit the yaml file that you applied before, and add the podSelector part, with 2 labels, webapp and frontend:

And apply this file again:

Add the podSelector part

Now, we will execute the same command as before, but with adding the 2 labels that we allowed in the network policy:

Add the 2 labels that were allowed in the network policy

As you can see, I was able to download the backend file without any problems. If I remove labels, and do another try, it failed:

Download the backend file

Traffic between namespaces

Now, we will allow the traffic between 2 namespaces. Try to run a pod, in another namespace, with labels that are allowed. And finally, download the backend webpage, in the StarWind namespace:

Download the backend webpage, in the starwind namespace

It works fine. Now, we will allow the traffic, only from the starwind namespace. Modify the namespaceSelector part, by adding a matchLabels:

 

Now, if I try to download the backend webpage, it will be blocked, why? Because we are in another namespace:

It is now very easy to allow/block traffic

As you can see, it is now very easy to allow/block traffic, between pods/namespaces, in the code. Your security colleagues will be now happy with the new improvements on your AKS clusters 🙂

Hey! Found Florent’s article helpful? Looking to deploy a new, easy-to-manage, and cost-effective hyperconverged infrastructure?
Alex Bykovskyi
Alex Bykovskyi StarWind Virtual HCI Appliance Product Manager
Well, we can help you with this one! Building a new hyperconverged environment is a breeze with StarWind Virtual HCI Appliance (VHCA). It’s a complete hyperconverged infrastructure solution that combines hypervisor (vSphere, Hyper-V, Proxmox, or our custom version of KVM), software-defined storage (StarWind VSAN), and streamlined management tools. Interested in diving deeper into VHCA’s capabilities and features? Book your StarWind Virtual HCI Appliance demo today!