Question

Difficulty: HardConfiguring Service Account Impersonation and Workload Identity

A Kubernetes application running on a Google Kubernetes Engine (GKE) cluster requires secure access to objects in a Google Cloud Storage bucket. To follow security best practices and avoid using downloadable service account key files, an engineer must configure Workload Identity. In what sequence should the engineer execute the configuration steps to enable identity delegation for the application?

  1. 1Create a target Google Cloud Service Account (GSA) and grant it the required Cloud Storage permissions on the target bucket.
  2. 2Grant the Workload Identity User role (roles/iam.workloadIdentityUser) to the Kubernetes Service Account (KSA) principal on the GSA resource.
  3. 3Annotate the Kubernetes Service Account (KSA) in GKE with the email address of the target Google Cloud Service Account.
  4. 4Update the Kubernetes Pod specification to specify the annotated Kubernetes Service Account and deploy the pod.

Answer

The correct operational sequence is to create the Google Cloud Service Account with bucket access permissions first, grant the Workload Identity User role to the Kubernetes Service Account on the GCP Service Account next, annotate the Kubernetes Service Account with the GCP Service Account email third, and finally deploy the Pod configured with the annotated Kubernetes Service Account.
The proper administrative sequence requires provisioning the GCP service account and assigning target bucket access, granting the `roles/iam.workloadIdentityUser` role to the KSA member on that GCP service account, annotating the Kubernetes service account with the GCP service account email, and finally binding the pod spec to the annotated Kubernetes service account.

Step-by-Step Solution

1
Provision the Google Cloud Service Account (GSA) and assign resource-level IAM roles.
A dedicated GCP identity exists with permissions to access Cloud Storage.
Before delegating identity, the destination GCP service account must exist and hold the required permissions.
2
Bind the Kubernetes Service Account (KSA) identity to the GSA via the `roles/iam.workloadIdentityUser` role.
GCP IAM trusts the specific KSA principal in the GKE Workload Identity pool to impersonate the GSA.
Impersonation requires explicit permission on the GSA resource granted to the KSA member string.
3
Annotate the KSA resource in Kubernetes with `iam.gke.io/gcp-service-account=GSA_EMAIL`.
The GKE control plane and metadata server link the KSA to the GSA email.
The GKE cluster must know which GSA email address to negotiate short-lived tokens for when the pod communicates with GCP APIs.
4
Specify `serviceAccountName: KSA_NAME` in the Pod deployment manifest.
The running pod assumes the annotated KSA identity and seamlessly authenticates to GCP.
The application container relies on the attached KSA to leverage the GKE Metadata Server for keyless authentication.

Key Concept

GKE Workload Identity configuration sequence
Rate this question