Skip to main content

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

High

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Confirm whether Workload Identity is enabled at the cluster level
    • Run on any machine with gcloud access:
    • If the output is null or empty, Workload Identity is not enabled and should be considered for activation.
  2. 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.
  3. 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_METADATA and migrate workloads before draining/deleting old pools.
  4. Identify workloads that currently depend on node service account credentials
    • On any machine with kubectl access, 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.
  5. 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 gcloud or 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.
  6. 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_METADATA mode:
    • 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).
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.