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:

VSAN from StarWind eliminates any need for physical shared storage just by mirroring internal flash and storage resources between hypervisor servers. Furthermore, the solution can be run on off-the-shelf hardware. Such design allows VSAN from StarWind to not only achieve high performance and efficient hardware utilization but also reduce operational and capital expenses.
Find out more about ➡ VSAN from StarWind

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 🙂


Views All Time
Views Today
Back to blog
The following two tabs change content below.
Florent Appointaire
Florent Appointaire is Microsoft Engineer with 5 years of experience, specialized in Cloud Technologies (Public/Hybrid/Private). He is a freelance consultant in Belgium from the beginning of 2017. He is MVP Cloud and Datacentre Management. He is MCSE Private Cloud and Hyper-V certified. His favorite products are SCVMM, SCOM, Windows Azure pack/Azure Stack and Microsoft Azure.