More Info:
Enable Workload Identity so pods authenticate to Google Cloud as dedicated service accounts rather than sharing node credentials. This provides fine-grained, per-workload access control.Risk Level
HighAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Confirm whether Workload Identity is enabled at the cluster level
- Run on any machine with
gcloudaccess: - If the output is
nullor empty, Workload Identity is not enabled and should be considered for activation.
- Run on any machine with
-
If not enabled, plan and enable Workload Identity for the cluster
- Decide the workload pool name (typically
PROJECT_ID.svc.id.goog) and assess impact on existing workloads and tooling (e.g., anything relying on node service account credentials). - Enable Workload Identity:
- Note: this changes the control-plane configuration; it does not retroactively change existing node pools.
- Decide the workload pool name (typically
-
Review and update existing node pools to use GKE metadata server
- List node pools:
- For each node pool, inspect its workload metadata setting:
- For node pools not set to
GKE_METADATA, schedule maintenance (this may recreate nodes) and update: - Alternatively, create new node pools with
--workload-metadata=GKE_METADATAand migrate workloads before draining/deleting old pools.
- List node pools:
-
Identify workloads that currently depend on node service account credentials
- On any machine with
kubectlaccess, look for pods not using projected service account tokens or that are known to call Google Cloud APIs: - Review deployment/statefulset manifests for these workloads to see how they obtain credentials (environment variables, mounted keys, or default ADC from node).
- Document which namespaces and service accounts will need Workload Identity mappings.
- On any machine with
-
Plan and apply per-workload migrations to Workload Identity
- For each identified workload:
- Choose/create a dedicated Google service account.
- Bind the Kubernetes service account in the relevant namespace to that Google service account using IAM policy binding (done via
gcloudor IaC, outside Kubernetes). - Update manifests so pods run under the intended Kubernetes service account (not
default) and do not rely on node credentials or legacy key files.
- Use the guidance in the Workload Identity documentation to complete these mappings and test that each workload still has the required access.
- For each identified workload:
-
Verify configuration after changes
- Re-run the cluster-level check:
Confirm it shows the expected
workloadPool(for example,PROJECT_ID.svc.id.goog). - For each node pool, confirm
GKE_METADATAmode: - Optionally, exec into a migrated pod and validate that Google Cloud API calls succeed using the intended service account (per your application’s logging or diagnostic commands).
- Re-run the cluster-level check:
Using kubectl
Using kubectl
kubectl cannot enable Workload Identity or change node pool metadata, because this finding is controlled entirely through the GKE/Google Cloud control plane (gcloud, console, or IaC). Use the cloud provider configuration steps described in the Manual Steps section to remediate this finding.
Automation
Automation

