Use dedicated Kubernetes service accounts for AKS workloads

Méthode de vérification

Méthode d'audit: Revue manuelle

Cette recommandation ne peut pas être vérifiée automatiquement. Une analyse la liste avec ces instructions lorsque vous passez --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.

Méthode de correction

Méthode de correction: Recommandation ou correctif d'infrastructure

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.