Share:
Twitter
LinkedIn
Facebook
Reddit
Whatsapp
Follow by Email
Reading Time: 4 minutes

So, you want to secure access to the kubernetes API server on your AKS cluster? Lucky for you that’s what this blog post is about. But first, why would you want to? The answer to that has to be security. By default, the Kubernetes API to manage your cluster is accessible from the internet over HTTPS.

I know, if you have followed some of my previous blogs about AKS you are probably thinking that my AKS cluster is already secured via Azure Active Directory and RBAC why do I need to lock it down further. The answer is that it really depends on your individual/company needs. Personally I would. It even warns me in the Azure security centre.

This can easily be achieved by using a  bit of Azure CLI.

Information

This only works on AKS clusters with standard load balancers. If you have followed my guides you should have one.

Let’s get to it

So, first, make sure you are connected to the AKS cluster that you want to secure. Then you are going to use the az aks update (https://docs.microsoft.com/en-us/cli/azure/ext/aks-preview/aks?view=azure-cli-latest#ext-aks-preview-az-aks-update) command. You will also be using the –api-server-authorized-ip-ranges switch to define the IP you want to allow.

For the below example I update my AKS cluster called pixel-aks-weu which resides in a resource group also called pixel-aks-weu. I will then authorise my current IP address. Don’t worry  will show you how to remove this later. Dynamic IP’s are such a pain 🙂

Awesome looks like it worked, no errors. Lets try a kubectl command.

Phew, still got access! If something did go wrong you should have something like in the image below.

Don’t worry if you enter the wrong IP address or it changes. You can always update it using the above command as that does not use the Kubernetes API.

Now my builds are failing!

If like me you are using Azure DevOps you will also need to allow their IP ranges. First, you will need to find what region your Azure DevOps region is running in. To do that login to Azure DevOps. https://dev.azure.com. Then click on Organization settings in the bottom left.

In the overview section, you will see what region you are running in. In my case, it’s West region.

One thing to note with Azure DevOps is you will need to whitelist all regions in that geography. So, in this case, I will also need to whitelist North Europe.

Microsoft publishes a JSON file every two weeks with the current IP address ranges for a specific Azure service or region, but it’s huge! It’s currently 30202 lines long.

You can download the latest JSON from https://www.microsoft.com/en-us/download/details.aspx?id=56519

To save you a headache you can use the following to get the information you need. In your terminal navigate to the location you downloaded the file to. Also, copy the filename as you will need that.

Then paste in the following, changing the region, file name and output file name.

Repeat for any other regions.

You should now have two txt files in the folder you ran the above commands in. Inside the files will be a load of IP addresses.

Now to allow all the new IP ranges. To do that just run the following. Making sure to change to match your resource group, aks cluster, you will also need to copy and paste the IP addresses from the txt files. Making sure to put a , in-between each copy. You will also need to add your IP address also.

This is due to the command overwriting what is there rather than add to the existing. You should now have something like this.

After some time you should have something like this.

Now you just have to make sure you update this when your build fails again 🙂

I will be investigating a way to do this via an Azure logic app so keep an eye out for that.

Remove the whitelisting

Luckily this bits nice and easy. All you have to do is use the same command above but instead of using an IP address just use “”. So it should look something like this.

All in all

It’s a bit of a pain, but as I am sure you are aware Security always is. I for one will be using this for all of my AKS clusters going forward and would advise you do too. Just remember if your pipeline fails due to it being unable to connect to the AKS cluster update the IP whitelist.

I hope you found this article helpful. If you have any comments or questions reach out. I am always happy to have a chat.

Share:
Twitter
LinkedIn
Facebook
Reddit
Whatsapp
Follow by Email

Pixel Robots.

I’m Richard Hooper aka Pixel Robots. I started this blog in 2016 for a couple reasons. The first reason was basically just a place for me to store my step by step guides, troubleshooting guides and just plain ideas about being a sysadmin. The second reason was to share what I have learned and found out with other people like me. Hopefully, you can find something useful on the site.

1 Comment

Danni · June 29, 2022 at 10:35 pm

Is this still the right approach after 2 years? In my case we use centralus which alone has more than 200 IP ranges which exceeds the limits of the –api-server-authorized-ip-ranges

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *