An enterprise is deploying an automated, non-interactive data processing pipeline to a Google Kubernetes Engine (GKE) cluster. The pipeline runs scheduled nightly jobs and microservices that query BigQuery datasets and write report outputs to Cloud Storage buckets without human intervention. Security policy requires that: Automated workloads must authenticate using non-human identities with the principle of least privilege. No long-lived downloadable service account keys (JSON files) may be generated or stored in cluster secrets. Workloads must not inherit the broad ambient permissions assigned to the underlying GKE cluster nodes. Which identity configuration should the security team implement to satisfy these requirements?

Configure GKE Workload Identity by binding the roles/iam.workloadIdentityUser role on a dedicated Google Service Account to the Kubernetes Service Account, and annotating the Kubernetes Service Account.: What GKE Workload Identity Is GKE Workload Identity is the recommended, best-practice mechanism for granting non-interactive, automated containerized workloads on Google Kubernetes Engine access to Google Cloud APIs. It enables a Kubernetes Service Account (KSA) running within a specific namespace to securely impersonate a Google Service Account (GSA) without requiring static credentials or JSON private keys. How It Meets the Requirements Automated, non-human identity: Workload Identity allows automated pods to obtain short-lived, auto-rotating OAuth 2.0 access tokens directly from the GKE metadata server, eliminating any requirement for human user credentials or interactive logins. No static private keys: Because authentication is mediated by the GKE metadata server via the Workload Identity pool ($PROJECT_ID.svc.id.goog), administrators do not need to generate, manage, or store long-lived JSON service account key files in Kubernetes Secrets. Least-privilege separation from node credentials: Each pod gets its own distinct identity based on its assigned KSA. Permissions are scoped strictly to the linked GSA rather than relying on or exposing the underlying Compute Engine VM node service account. Key Advantages and Capabilities Role-based binding: Grants the roles/iam.workloadIdentityUser IAM role on the target GSA specifically to the principal member string serviceAccount:$PROJECT_ID.svc.id.goog[$NAMESPACE/$KSA_NAME]. Kubernetes metadata annotation: Connects the KSA to the target GSA using the iam.gke.io/gcp-service-account=$GSA_NAME@$PROJECT_ID.iam.gserviceaccount.com annotation. Automatic credential rotation: Access tokens generated for pods are short-lived and automatically refreshed by the Google Cloud client libraries and metadata server. Comprehensive auditability: Cloud Audit Logs capture the exact Google Service Account identity performing BigQuery queries and Cloud Storage operations. Why This Is Optimal Workload Identity completely eliminates the attack surface associated with credential exfiltration from local pod storage, enforces strong workload isolation across namespaces, and natively supports non-interactive execution for automated pipelines.