Connecting to an AKS Cluster Non Interactivity — Part 1

Adrian Hynes
4 min readNov 3, 2020



If you’ve ever tried connecting to an AKS Cluster and you come across the following screen and wish you could just connect via a one line command, then this series of articles is for you.

Now you might be thinking, hold on, I can connect to my AKS Cluster Non Interactively using the following command with --admin flag. Yes you are correct. This brings us on to Azure AKS Roles.

az aks get-credentials --resource-group <resource group> --name <cluster name> --admin

Azure AKS Roles

The two built in Azure AKS roles we want to talk about when connecting to an AKS cluster are Azure Kubernetes Service Cluster Admin Role and Azure Kubernetes Service Cluster User Role

Azure Kubernetes Service Cluster Admin Role

This Azure Roles maps directly to the cluster-admin kubernetes role. If this role is assigned to your identity, then you can simply use the az aks cli to connect to your cluster non interactively.

az aks get-credentials --resource-group <resource group> --name <cluster name> --admin

But and there is a but, there are some downsides to assigning this role to identities:

  • This roles gives you access to perform any actions within the cluster and so is considered very highly privileged.
  • This token (see the sample kubeconfig file above)is valid for up to 2 years and cannot be revoked. Employees who has left the company could potentially access your cluster with this kubeconfig file

Azure Kubernetes Service Cluster User Role

This Azure Role gives you the ability to generate what I like to call a skeleton kubeconfig file. This file contains details about the cluster and how you will authenticate and authorize to it, BUT importantly contains no information on your identity.

az aks get-credentials --resource-group <resource group> --name <cluster name>

When you execute a kubectl * command, a flow is kicked off to authenticate you identity, this is when you get the URL, a CODE and potentially involves you logging into Azure.

Once you authenticate successfully you’ll notice some new additions (access-token, refresh-token, expires-in, expires-on) to your kubeconfig file, which relate to your identity details. These details will be used in AKS to check if you have access to certain resources. We’ll dig deeper into this flow later.

Now you’ve authenticated to the cluster with your identity, you will need a corresponding Cluster Role / Role and Cluster Role Binding / Role Binding with your UPN (Unique Principal Name) or AD Group Name/Object ID in your Cluster to take over the Cluster RBAC side of things to decide what you can and cannot do within the cluster. If you don’t have this or do not have permissions, you will get an error like the following:

Some of you now might be thinking, I’ve only ever seen this interactive mode once or a handful of times. You may well be right. The presence of the refresh-token which we will talk about later, will automatically refresh your identity details when they expire. The refresh-token lives for 90 days.

In Part 2, we’re going to dive into some foundation items like OAuth2, OIDC, JWT and the Microsoft Identity Platform.

Go to Part 2 now:



Adrian Hynes

Cloud Platform Architect. Opinions and articles on medium are my own.