Introduction

az aks create now defaults to managed identity for many scenarios, which replaces older service principal setup in standard workflows. This change improves credential management because Azure handles identity lifecycle and secret rotation automatically. Teams upgrading scripts should understand what changed and which flags still control identity behavior.

From Service Principal to Managed Identity

Historically, AKS clusters often used explicitly created service principals with client secrets. Newer Azure CLI behavior encourages managed identity, reducing manual secret handling and lowering operational risk.

az aks create   --resource-group rg-demo   --name aks-demo   --node-count 2   --generate-ssh-keys

If you do not provide service principal arguments, CLI commonly provisions identity based access for cluster resources. Always review command output to confirm identity mode.

Checking Cluster Identity Mode

After creation, inspect cluster properties to verify whether system assigned or user assigned managed identity is configured.

az aks show   --resource-group rg-demo   --name aks-demo   --query identity

For user assigned identity, pass identity resource IDs during creation and ensure required role assignments exist before deployment.

az aks create   --resource-group rg-demo   --name aks-demo   --assign-identity /subscriptions/xxx/resourceGroups/rg-demo/providers/Microsoft.ManagedIdentity/userAssignedIdentities/aks-id

Updating Existing Automation Scripts

Legacy CI scripts may still pass --service-principal and --client-secret. If your organization has moved to managed identity, simplify scripts by removing secret injection and replacing downstream role assumptions with identity based role bindings.

Document this migration in runbooks so operators know why new clusters no longer require explicit principal credentials.

Role Assignment and Registry Access

Managed identity removes secret rotation burden, but it still requires correct role assignments for cluster operations. A common example is granting pull permission to Azure Container Registry.

1ACR_ID=$(az acr show --name myregistry --query id -o tsv)
2PRINCIPAL_ID=$(az aks show   --resource-group rg-demo   --name aks-demo   --query identity.principalId -o tsv)
3
4az role assignment create   --assignee-object-id "$PRINCIPAL_ID"   --assignee-principal-type ServicePrincipal   --scope "$ACR_ID"   --role AcrPull

For user assigned identity, assign roles to that identity resource before cluster dependent workloads are deployed. In environment promotion pipelines, keep these assignments declarative and audited so production access remains predictable.

If cluster creation fails with permission errors, inspect both subscription role scope and managed identity propagation delays. Retries may be needed immediately after new identity creation in automation scripts.

During migration, create a checklist for identity mode, role assignments, registry pull access, and workload permissions to Key Vault or storage resources. Running this checklist in every environment prevents surprises where development succeeds but production lacks required access scopes.

When using infrastructure as code, keep identity resources and role assignments in the same deployment layer as AKS definitions. This prevents hidden manual dependencies and makes disaster recovery reproducible across subscriptions and regions.

Set explicit ownership for identity governance so platform and security teams agree on who approves new role grants, who reviews existing permissions, and how exceptions are tracked over time. Governance clarity prevents configuration drift after initial migration.

A small post creation validation script that checks cluster identity and core role bindings can catch most misconfigurations before workloads are deployed.

This check should run in CI after provisioning.

Reliability improves.

Common Pitfalls

• Assuming old service principal flags are still required for new clusters.
• Not checking resulting identity type after cluster creation.
• Missing required role assignments for user assigned identities.
• Mixing identity models across environments without documentation.
• Keeping obsolete secret handling in CI pipelines after migration.

Summary

• AKS defaults increasingly favor managed identity over service principals.
• Validate identity mode after cluster provisioning.
• Use user assigned identity only when workload design requires it.
• Update automation to remove unnecessary secret handling.
• Document identity conventions across environments.