Skip to content

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.
  • --sync style 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

Sources