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

Did you know that even when you have enabled Azure AD integration with your AKS cluster, a subscription Owner and Contributor can still access you AKS cluster with the -admin switch? In fact, anyone who is a member of the Azure Kubernetes Service Cluster Admin Role (https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#azure-kubernetes-service-cluster-admin-role) can. You were able to use Kubernetes RBAC (Role Based Access Control) to limit this before, but I have not seen many people do this, or even aware you could. (https://pixelrobots.co.uk/2020/06/use-azure-rbac-to-define-access-to-kubeconfig-in-azure-kubernetes-service-aks/)

Now you can easily switch –admin access on or off using a simple switch with az aks commands. You can even do it at cluster creation.

Warning

This is still in preview and should not be used for production clusters.

So, for this you will need the AKS-Preview extension of AZ CLI. If you do not already have this installed, you can add it using.

Shell

Or to update your existing use.

Shell

Register the preview feature

First, you need to register the preview feature. To do that use the following command.

Shell

After some time, the feature should be registered. You can verify by using the following command.

Shell

When the above shows registered you need to refresh the Microsoft.ContainerService resource provider. To do this just use the following.

Shell

Disable local admin on an existing cluster

Now that the preview feature is registered its time to test it out. I set my current Kubernetes context using the –admin switch. You will see the cluster name in my terminal window now says -admin at the end. I have full cluster access and can view anything in the cluster without having to specify any Azure AD credentials.

The following command is used to disable the local admin account. Just change the resource group and cluster name.

Shell

As I am already connected with the admin access, I still have full rights on the cluster. The cluster I am using in this blog post currently does not have Azure AD integration enabled.

So if I try to get the cluster credentials using az aks get-credentials I will get errors, for both user and admin.

Now if I enable Azure AD integration and make myself a member of the group, I should be able to get the cluster credentials but not be allowed to use the –admin switch. (https://docs.microsoft.com/en-us/azure/aks/managed-aad)

So that works as expected! A great win for security and super easy. One thing to note is as I have already pulled down the admin context before the switch, I am able to use kubectl to switch to it. So, if you enable this feature on an existing cluster and do not want admin access, make sure your kube config file does not have the context.

Enable local admin on an existing cluster

If for some reason you need to enable the admin access on the cluster again you can use the following command to do so. Just change the resource group and cluster name to yours.

Shell

What about when creating a new cluster?

Well, this is nice and easy too. Just add the –disable-local-accounts switch to your cluster creation command. An example is below.

Shell

Now when you try to connect to the new cluster with –admin you will not be able to.

TLDR

You can use a simple switch to disable and enable the use of –admin switch when getting AKS clusters credentials. This can be disabled on cluster creation and disabled and enabled on existing clusters. This new method is a lot easier than the previous method of using RBAC objects inside the AKS cluster.

I hope you found this article helpful. If you have any questions, please reach out.

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.

5 Comments

Mark · June 3, 2021 at 12:51 am

Hi.

Useful post – thank you.

There was one thing that initially tripped me up when following it – a one-off step you probably did a while ago yourself but might be worth adding into your post…

You need to add the aks-preview extension to the Azure CLI before you can use the –disable-local-accounts switch; else it is not recognized and you receive an error

The command for this doing is ‘az extension add –name aks-preview’

Also, just a small point, but your screenshot after running the ‘az aks update –resource-group deleteme –name betatesting –disable-local-accounts’ command I assume meant to show the result of the command being executed, but it doesn’t unless I’m missing something.

    Pixel Robots. · June 3, 2021 at 8:27 am

    Hello, good shout about the AKS-Preview extension being needed.

    The image looks right to me. once you run the az aks update command it returns the json of your aks cluster which is what is seen in the image.

    Thanks

      Mark · June 3, 2021 at 12:56 pm

      Ok 🙂

      Re the screenshot, I guess I was expecting the image to show the “disableLocalAccounts”: true section as to demonstrate the impact of the command… only visible if you scroll up a little. Doesn’t really matter either way 🙂

hakabo · June 17, 2021 at 6:58 pm

Thanks for this post – really useful!
If I disable local accounts and then run my terraform again, it complains of Status=400 Code=”BadRequest” Message=”Getting static credential is not allowed because this cluster is set to disable local accounts.”
How do I get around this? I’m logging in via az login with an account that is has the role Azure Kubernetes Service RBAC Cluster Admin.
thanks

    Pixel Robots. · June 18, 2021 at 10:05 am

    What command are you using to get the credentials?

Leave a Reply

Avatar placeholder

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