Microsoft Defender for Cloud · Azure Kubernetes Service
Kubernetes clusters should disable automounting API credentials
Written and reviewed by Emnode · Last reviewed
What does the recommendation "Kubernetes clusters should disable automounting API credentials" check?
Flags pods on an AKS cluster whose spec leaves 'automountServiceAccountToken' at its default of true, which mounts a service account token into the container at /var/run/secrets/kubernetes.io/serviceaccount so the workload can call the Kubernetes API. It is an admission-control check evaluated by the Azure Policy add-on (Gatekeeper) against each pod and its service account. It does not check what that token is allowed to do: RBAC role bindings, the scope of the token or whether the API server is reachable are out of scope, and it does not cover tokens you mount yourself through a projected volume.
Why does "Kubernetes clusters should disable automounting API credentials" matter?
A pod that does not talk to the API server has no reason to carry an API token, yet by default every pod gets one. If an attacker lands code execution in such a pod, through a vulnerable dependency or an exposed endpoint, that mounted token becomes a ready-made cluster credential: they can enumerate secrets, list other pods or, with permissive RBAC, escalate towards cluster-admin without ever leaving the container. It is one of the most common privilege-escalation paths reported against AKS, precisely because the credential is present by default and developers rarely notice it. Disabling the automount removes the credential from workloads that never needed it, so a single compromised container can no longer be used as a pivot into the control plane. The business consequence of getting this wrong is a contained code-execution bug turning into a full cluster and data-plane breach, with every workload and secret on the cluster in scope.
How do I fix "Kubernetes clusters should disable automounting API credentials"?
- Set 'automountServiceAccountToken: false' on the pod spec, or on the service account the pod uses, for every workload that does not call the Kubernetes API; for the few that do, leave it true and grant least-privilege RBAC instead.
- Enable the Azure Policy add-on so the rule is enforced in-cluster: az aks enable-addons --addons azure-policy --name <cluster> --resource-group <rg>, which installs Gatekeeper and syncs the constraint.
- Assign the built-in policy in Deny so non-compliant pods are rejected at admission. Look the definition up by name rather than hardcoding its GUID: pid=$(az policy definition list --query "[?displayName=='Kubernetes clusters should disable automounting API credentials'].name" -o tsv); az policy assignment create --name aks-no-automount --policy "$pid" --params '{"effect":{"value":"Deny"}}' --scope <cluster-resource-id>.
Remediation script · bash
# 1. Turn on the Azure Policy add-on so Gatekeeper starts auditing the cluster.
az provider register --namespace Microsoft.PolicyInsights
az aks enable-addons --addons azure-policy \
--resource-group rg-prod --name aks-prod
# Confirm the policy and gatekeeper pods are running.
kubectl get pods -n kube-system -l app=azure-policy
kubectl get pods -n gatekeeper-system
# 2. Assign the built-in pod security baseline initiative in AUDIT first.
# Look the initiative up by its exact display name, never paste a GUID.
SCOPE=$(az aks show -g rg-prod -n aks-prod --query id -o tsv)
SETID=$(az policy set-definition list \
--query "[?displayName=='Kubernetes cluster pod security baseline standards for Linux-based workloads'].name" -o tsv)
az policy assignment create \
--name aks-pod-baseline \
--policy-set-definition "$SETID" \
--scope "$SCOPE" \
--params '{"effect":{"value":"audit"},"excludedNamespaces":{"value":["kube-system","gatekeeper-system","azure-arc"]}}'
# 3. Fix the workloads (in each pod spec, securityContext):
# privileged: false | runAsNonRoot: true | runAsUser: 1000
# allowPrivilegeEscalation: false | readOnlyRootFilesystem: true
# capabilities: { drop: ["ALL"] } and add back only what is needed.
# 4. Once audit is clean except for named exceptions, ENFORCE.
az policy assignment update --name aks-pod-baseline \
--set parameters.effect.value=deny Full walkthrough (console steps, edge cases and verification) in the lesson Enforce AKS pod security.
Is "Kubernetes clusters should disable automounting API credentials" a false positive?
A pod that genuinely needs API access, for example an ingress controller or cert-manager that reconciles cluster resources, will correctly flag if you have blanket-disabled the token, and forcing it off there breaks the workload. The right exception is to set 'automountServiceAccountToken: true' on that specific service account, pair it with a tightly scoped RBAC role, and exempt only that namespace from the Deny assignment rather than auditing the whole cluster down.
More Azure Kubernetes Service controls
- Azure Kubernetes Service clusters should have Defender profile enabled
- Azure Kubernetes Service clusters should have the Azure Policy add-on for Kubernetes installed
- Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management)
- Container CPU and memory limits should be enforced
- Container images should be deployed from trusted registries only
- Container with privilege escalation should be avoided
- Containers sharing sensitive host namespaces should be avoided
- Diagnostic logs in Kubernetes services should be enabled
- Immutable (read-only) root filesystem should be enforced for containers
- Kubernetes API server should be configured with restricted access
- Kubernetes clusters should be accessible only over HTTPS
- Kubernetes clusters should not use the default namespace