In this post, I’ll explain to you how you can use Azure Policy to restrict the creation of load balancers with a public IP in AKS using Azure policy.
Azure policy is a way to ensure your Azure deployments follow your standards. Policies are a set of restrictive rules, that control what can be deployed in your Azure environment. They do not control who gets access to your environment, that is controlled through role-based access control.
Azure policy has a plugin available that allows you to configure Azure policy on top of Kubernetes as well. This gives you the ability the use Azure policy to manage the state of your resources inside a Kubernetes cluster. To make this work, Azure policy under the covers uses a combination of Gatekeeper, Open Policy Agent, and admission webhooks.
To restrict the creation of public load balancers, we’ll use Azure policy on a new cluster. Let’s get this going:
For this small experiment, I created a new cluster with Azure policy enabled at the creation time:
az group create -n aks-policy -l westus2 az aks create -n aks-policy -g aks-policy --enable-managed-identity --enable-addons azure-policy --node-count 1 az aks get-credentials -n aks-policy -g aks-policy
I then went into the portal to assign a new Azure policy to this cluster. The policy I was looking for was: “Kubernetes clusters should use internal load balancers”.
Once you open Azure policy in the portal, select the Kubernetes category and look for the keyword “internal”, as shown in the picture below:
The next screen shows you the actual policy in JSON, and giving you the ability to assign it:
Next up, you have to select the scope for this policy. In my case, I’m only assigning it to the resource group of the cluster. In your case, you could apply it to your full subscription or management group if you want to have it apply everywhere:
Next, you can configure certain inclusion/exclusions. In this example, I’ll have it apply to all namespaces except the default 3 and the internet namespace:
Finally, we can review and create the policy:
Once you hit the create button, you’ll get a popup confirming the policy is being applied. It can take up to 30 minutes for it to appear on your cluster:
After those 30 minutes have passed, let’s try this out!
Trying out the policy
To verify the policy, I’ll be using an example from my latest book: the guestbook all-in-one example, which includes a public load balancer.
Let’s start by trying it out in the default namespace:
kubectl create ns blocked kubectl create -n blocked -f https://raw.githubusercontent.com/PacktPublishing/Hands-on-Kubernetes-on-Azure-Third-Edition/main/Chapter05/guestbook-all-in-one.yaml
This resulted in the (expected) error:
Let’s try the same using an internal load balancer:
k create -f https://raw.githubusercontent.com/NillsF/blog/master/aks-policy/ilb.yaml -n blocked
Which does not result in an error, since this is allowed:
Let’s try creating a public load balancer in the internet namespace:
kubectl create ns internet kubectl create -n internet -f https://raw.githubusercontent.com/PacktPublishing/Hands-on-Kubernetes-on-Azure-Third-Edition/main/Chapter05/guestbook-all-in-one.yaml
Which – as expected – succeeded without the error:
This shows you how to use Azure policy to limit the creation of Azure public load balancers.
This post explained to you how to use Azure policy to limit the creation of public services in AKS. This post showed you how to create a new cluster with Azure policy enabled, how to assign the “Kubernetes clusters should use internal load balancers” policy to your cluster. You then saw how the policy shows a visual error when public services get created.