Use dedicated service accounts for EKS Auto Mode workload identities

Kako se proverava

Metod provere: Komanda ljuske

out=$(kubectl get pods -A -o go-template='{{range .items}}{{.metadata.namespace}} {{.metadata.name}} {{.spec.serviceAccountName}}{{"\n"}}{{end}}') || exit 1
bad=$(printf '%s\n' "$out" | awk -v ex='^(kube-system|kube-public|kube-node-lease)$' 'NF && $1 !~ ex && ($3=="default" || $3=="<no")')
if [ -z "$bad" ]; then echo compliant; else printf '%s\n' "$bad" | head -n 25; fi

Očekivani izlaz

compliant

Kako se ispravlja

Metod ispravke: Smernica ili zakrpa infrastrukture

Use dedicated Kubernetes service accounts for EKS Auto Mode workloads and map AWS access to those accounts through EKS Pod Identity, or IRSA where required. Create one least privilege IAM role per application or permission boundary, update workloads to reference the intended serviceAccountName, disable token automounting where Kubernetes API access is not needed, and restrict node instance profile access so pods cannot inherit broader node credentials. • Create a dedicated Kubernetes service account for each application or distinct AWS permission boundary instead of sharing the namespace default service account. • Associate that service account with a least privilege IAM role by using EKS Pod Identity where supported, or IRSA where Pod Identity is not supported or not selected. For EKS Pod Identity, create an association between the Kubernetes namespace, service account, and IAM role.

Proverite ovaj računar

Pokrenite ovo na računaru za koji imate dozvolu za proveru. Skeniranje radi u režimu samo za čitanje.

tmaegis scan --target eks-auto