Use dedicated Kubernetes service accounts for AKS workloads

How it is checked

Audit method: Manual review

This recommendation cannot be checked automatically. A scan lists it with these instructions when you pass --include-manual.

For each namespace, verify that workloads do not use the default service account unless required, and confirm that the default service account has no custom role bindings beyond baseline defaults. Review service accounts used by individual workloads to ensure permissions follow least privilege, and confirm automountServiceAccountToken is disabled where token access is not needed. • Review each namespace for pods and workload controllers that use the default service account, and flag any use that is not explicitly required.

How it is fixed

Fix method: Guidance or infrastructure patch

Use a dedicated Kubernetes service account for each AKS workload that requires identity, and replace use of the namespace default service account wherever it is not explicitly required. Limit each service account to only the Kubernetes permissions and Azure resource access needed by that workload, and prevent service account tokens from being mounted into pods unless token access is required. 1. Create a separate Kubernetes service account for each workload or application boundary that requires distinct access. 2. Bind each service account only to the minimum required Kubernetes Role or ClusterRole, and avoid granting custom permissions to the namespace default service account. Prefer a RoleBinding in the required namespace when permissions do not need to apply throughout the cluster. 3. Set automountServiceAccountToken: false for pods that do not need a service account token. 4.