Deploying AKS via AzureCLI and Service Principal Names

I am fairly new to the Kubernetes world. I would say that every day is still a learning experience for me. This weekend I was trying to redeploy some AKS clusters for a demo I need to do on Tuesday. However, I kept running into an issue with my WSL (Windows Subsystem for Linux). At least, I thought it was.

When you deploy an AKS cluster using the portal or from Azure CLI and don’t declare a service principal the process should automatically create a service principal name (SPN) for you.

However, I was using the same cluster name and same resource group name from previous demos and kept getting errors that the “Operation failed with status: ‘Bad Request’. Details: Service principal clientID: <client id> not found in Active Directory tenant <tenant id> , Please see for more details”

After a bit of research, I discovered that there is a JSON file called aksServicePrincipal.json that is created when you don’t specify a “–service-principal” It was trying to refer to an SPN within that JSON. This JSON file exists on the host that you are deploying the AKS clusters from. It is located at ~/.azure/aksServicePrincipal.json.

The first thing I did was delete the file. Everything worked just fine. However, I am not sure that was the best practice. Actually, I think the best practice would have been to have created the SPN myself and declare that SPN during the deployment.

I did find this command to clean up old SPN’s after I have removed an AKS cluster. However, this just removed the SPN from the tenant and didn’t remove anything from the aksServicePrincipal.json file.

az ad sp delete --id $(az aks show -g myResourceGroup -n myAKSCluster --query servicePrincipalProfile.clientId -o tsv)

So for best practices, instead of deleting the JSON. I edited the file using VI and removed the service principle. This will help me keep everything nice and clean.

Final Thoughts

So, my final thoughts on this? If this wasn’t a demo environment I would have used a pre-created SPN that already had all the correct access. Since this is only for demo environments, a cleanup process is still a good plan.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s