Trying to wrap my head around this situation.
I have an ARM template to deploy AKS cluster and the template includes servicePrincipalProfile. I use a script to create a new SP, assign required role (AcrPull in a specified scope in a different subscription) and then use the credentials in the template.
I want to use the same ARM template to update the AKS cluster but I fail to reuse the SP. I do not store the ID and secret anywhere. I can obtain the SP Id from the resource, but i'm still missing the password. Keeping it blank does not work.
What is the best way to handle a similar situation? Thinking out loud - create the template without custom SP and then obtain the SP Id from the AKS resource and assign the role to the automatically created SP?
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Thanks for the feedback! We are currently investigating and will update you shortly.
You should be able to see the info for the service principal after creating it as documented here
https://docs.microsoft.com/en-us/azure/aks/kubernetes-service-principal#manually-create-a-service-principal
Once you have info, you can pass it into your template to reuse that service principal. Or you could store it as a secret in keyvault and pull that info. Same idea though.
@MicahMcKittrick-MSFT is it worth storing the SP credentials in a keyvault? I'm trying to avoid this step. Once they are stored in AKS cluster I don't need to access them though. If I needed to use the SP somewhere else, I'd create new credentials, so I'm treating all credentials in a "create & forget" manner.
What I missed is that you can use an empty secret in the template and AKS will keep the current secret, not replace it with an empty string. This works for me.
Sorry for confusion, all sorted!
I use a reference to a principal in keyvault. However, updating the client secret in keyvault does not automatically work. It seems to be pulled once during installation. Applying the ARM-template again give me the error "Changing property 'servicePrincipalProfile.secret' is not allowed.". How is this suppose to work in this scenario?
@kwaazaar – did you find a solution to that? I'm running into the same issue. I have an ARM template with a parameter for servicePrincipalProfile.secret. When I change the parameter and re-deploy I get an error during deployment validation:
Changing property 'servicePrincipalProfile.secret' is not allowed
This could block us from using ARM to manage the cluster, since credential rotation is very important! Perhaps the behaviour mentioned by @ondrejhlavacek could be used, to set the secret to an empty string on deployments after the first.