Rerunning `az aks create` with updated service principal fails

Describe the bug

I have a script that creates a service principal and a AKS cluster. It fails when I run it the second time. Seeing as the Azure CLI is supposed to be idempotent, I would expect the following to work.

• I update an existing service principal with the same name: az ad sp create-for-rbac --skip-assignment --name "http://sp-foo-bar" This seems to work, as the azure cli responds with: Found an existing application instance of "c3d04f78-***(truncated)-517157647687". We will patch it

I then expect when I call aks create on an existing cluster with my new service principal secret, that it will do the update steps necessary to rotate the credentials. What it does is, it throws an error:

Operation failed with status: 'Bad Request'. Details: Changing property 'servicePrincipalProfile.secret' is not allowed.

Other people seem to have the same issues with arm templates here: https://github.com/MicrosoftDocs/azure-docs/issues/39788#issuecomment-551861676

Command Name

az ad sp create-for-rbac --skip-assignment --name "http://sp-foo-bar"

az aks create -n mycoolcluster `
    --generate-ssh-keys `
    --attach-acr ${ContainerRegistryName} `
    --location ${Location} `
    --vnet-subnet-id ${SubnetId} `
    --service-principal ${ServicePrincipalAppId} `
    --client-secret ${ServicePrincipalClientSecret} `
    -o none

Errors:

Operation failed with status: 'Bad Request'. Details: Changing property 'servicePrincipalProfile.secret' is not allowed.

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

• Create an AKS cluster with a custom provided service principal
• Update the service principal with az ad sp create
• Call aks create with the updated service principal

Environment Summary

Linux-5.5.9-200.fc31.x86_64-x86_64-with-fedora-31-Thirty_One
Python 3.7.6

azure-cli 2.2.0

Extensions:
application-insights 0.1.4

Additional Context

[krowlandson]

I’ve come across this issue too, but after researching this I came to the conclusion that this may be by design. You appear to have already followed the best practice of creating a custom SPN rather than relying on az aks create but this command doesn’t provide the ability to change the SPN.

The following article provides the recommended approach to update or rotate the credentials for Azure Kubernetes Service (AKS): https://docs.microsoft.com/en-us/azure/aks/update-credentials

As long as you follow a suitable method to generate a new secret for your SPN, you can use the following command to update your cluster configuration:

az aks update-credentials \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --reset-service-principal \
    --service-principal $SP_ID \
    --client-secret $SP_SECRET

Once updated, you can delete the old secret.

During my research, I also tried generating secrets using the Azure Portal. This uncovered an unexpected issue where the auto-generated value often started with a non-alphanumeric character causing the above to fail. I’d recommend using the approach documented above as it will be much more robust.

As an alternative, have you considered using a Managed Identity? This greatly simplifies setup and operations, and even handles key rotation automatically: https://docs.microsoft.com/en-us/azure/aks/use-managed-identity

[navba-MSFT]

@GeeWee The plan suggested here should help in this scenario. We will now proceed with closure. If you face the similar issue with most recent version of CLI, feel free to reopen this thread. We would be happy to assist you further.