Credential Rotation¶
Credential rotation in AKS includes more than Kubernetes certificates. You also need rotation plans for kubeconfig access, workload credentials, image pull identities, and external secrets.
Prerequisites¶
- You know which identities and certificates exist in the cluster.
- Application teams know how to recover after rotation events.
- A change window and rollback communication plan are prepared.
When to Use¶
- Scheduled certificate rotation.
- Secret expiration or emergency compromise response.
- Migration from static credentials to workload identity.
- Kubelet identity replacement or registry-permission remediation.
- Key Vault access-model migration before or after a security review.
Procedure¶
flowchart TD
A[Inventory cluster, kubelet, workload, and secret access identities] --> B[Grant replacement identity or access path first]
B --> C[Rotate certificate, federated credential, or Key Vault access model]
C --> D[Validate fresh token exchange, image pull, and secret mount behavior]
D --> E[Remove old grants only after continuity is proven] 1. Inventory the credential paths¶
Record which AKS identity owns each access path before rotating anything:
- Cluster certificates and kubeconfig for API access.
- Control-plane identity for Azure resource mutation.
- Kubelet identity for ACR pulls and other node-side Azure access.
- Workload identity for pod-to-Azure-resource token exchange.
- Key Vault CSI path for mounted files and any synced Kubernetes secrets.
az aks show \
--resource-group "$RG" \
--name "$CLUSTER_NAME" \
--query "{controlPlaneIdentity:identity,kubeletIdentity:identityProfile.kubeletidentity,issuer:oidcIssuerProfile.issuerUrl,workloadIdentity:securityProfile.workloadIdentity,keyVaultAddon:addonProfiles.azureKeyvaultSecretsProvider}" \
--output yaml
kubectl get serviceaccount \
--all-namespaces
kubectl get secretproviderclass \
--all-namespaces
| Command | Purpose |
|---|---|
az aks show | Show cluster identity and Key Vault add-on details. |
--resource-group | Resource group that contains the AKS cluster. |
--name | Name of the AKS cluster. |
--query | Selects identity, issuer, and add-on fields. |
--output | Output format for the result. |
kubectl get serviceaccount | List service accounts across namespaces. |
kubectl get secretproviderclass | List Key Vault SecretProviderClass resources. |
2. Rotate cluster certificates separately from workload identity¶
Cluster certificate rotation is not the same as workload identity rotation. Run it on its own change plan, then refresh clients.
az aks rotate-certs \
--resource-group "$RG" \
--name "$CLUSTER_NAME" \
--yes
az aks get-credentials \
--resource-group "$RG" \
--name "$CLUSTER_NAME" \
--overwrite-existing
| Command | Purpose |
|---|---|
az aks rotate-certs | Rotate the cluster certificates. |
--resource-group | Resource group that contains the AKS cluster. |
--name | Name of the AKS cluster. |
--yes | Skip the confirmation prompt. |
az aks get-credentials | Refresh the local kubeconfig after rotation. |
--resource-group | Resource group that contains the AKS cluster. |
--name | Name of the AKS cluster. |
--overwrite-existing | Overwrite any existing kubeconfig entry for the cluster. |
3. Rotate federated credentials without workload interruption¶
Federated identity credentials are safe to rotate when you overlap old and new trust instead of replacing it in one cut:
- Create the replacement federated identity credential first.
- Keep the same Kubernetes service account subject during the test window when possible.
- Grant downstream Azure access to the replacement identity target before switching production traffic.
- Start a canary pod and validate fresh token exchange.
- Remove the old federated identity credential only after the canary proves continuity.
If you must change the namespace or service account name, treat the change as a new subject and overlap both credential definitions during transition.
4. Migrate Key Vault access model safely¶
When moving between Key Vault access policies and Azure RBAC:
- Grant the new authorization model first.
- Start a fresh pod that mounts the same
SecretProviderClass. - Validate both mounted file content and any synced Kubernetes secret.
- Remove the old authorization path only after refresh and remount succeed.
Running pods can continue to hold already-mounted values in memory or on disk until the next refresh cycle, so a revoke can appear delayed from the application's perspective.
5. Handle kubelet identity rotation deliberately¶
Kubelet identity changes affect node-side Azure access, especially ACR pulls.
- Distinguish control-plane identity failures from kubelet identity failures before granting permissions.
- For ACR pull issues, grant the required registry role to the kubelet identity, not to workload identities.
- Validate by forcing a fresh image pull, because already-running pods can hide the break until restart or reschedule.
Replacement implications:
- Existing running pods may stay healthy until a new image pull is required.
- Cluster scale-out, new deployments, and node replacements expose kubelet identity mistakes quickly.
6. Set correct secret refresh expectations¶
The Key Vault CSI refresh path is eventual, not immediate:
- Mounted files refresh after the CSI provider's refresh cycle detects a new Key Vault version.
--syncstyle secret synchronization creates or updates a Kubernetes secret copy, but it does not make environment variables inside already-running containers reload automatically.- Applications that read secrets only at startup usually need a restart or rollout to consume the new value, even when the mounted file or synced secret has already updated.
Verification¶
kubectl auth can-i get pods --all-namespaces
kubectl get pods \
--all-namespaces
kubectl describe serviceaccount "$SERVICE_ACCOUNT_NAME" \
--namespace "$NAMESPACE"
kubectl describe pod "$POD_NAME" \
--namespace "$NAMESPACE"
kubectl get secret "$SECRET_NAME" \
--namespace "$NAMESPACE" \
--output yaml
Rollback / Troubleshooting¶
- If client access fails after certificate rotation, refresh kubeconfig and verify Entra authentication plugins.
- If workloads lose Azure access, inspect workload identity federation settings and the Token Exchange Failure playbook.
- If the issuer changed or a cluster migration occurred, use OIDC Issuer Mismatch.
- If token exchange fails after a credential edit, use Audience Mismatch.
- If Key Vault still fails after apparent RBAC success, use RBAC Success but Key Vault Still Fails.
- If image pulls fail after kubelet credential changes, validate ACR integration and kubelet identity role assignments immediately.
- If Defender for Containers starts surfacing identity-related alerts after a rotation, validate the alert against the cluster's Defender for Containers coverage before creating a suppression rule.
See Also¶
- Identity and Secrets
- Microsoft Entra Workload Identity
- Identity Model Comparison
- Azure Key Vault CSI Driver
- Defender for Containers
- Security
- Image Pull Failure