Examkin

Question

Difficulty: EasyConfiguring Service Account Impersonation and Workload Identity

What is the correct sequential order of administrative steps to configure GKE Workload Identity so that a Pod running in a Kubernetes namespace can access Google Cloud APIs using a dedicated Google Service Account?

  1. 1Create the Google Service Account (GSA) and grant it the necessary IAM roles for the Google Cloud resources.
  2. 2Create the Kubernetes Service Account (KSA) in the specific GKE cluster namespace where the application workload runs.
  3. 3Add an IAM policy binding granting the Workload Identity User role (roles/iam.workloadIdentityUser) on the GSA to the KSA principal.
  4. 4Annotate the Kubernetes Service Account (KSA) with the email address of the target Google Service Account (GSA).

Answer

The correct sequence begins by creating the Google Service Account (GSA) with required GCP resource permissions, followed by creating the Kubernetes Service Account (KSA) in the cluster namespace, then adding the IAM policy binding to grant roles/iam.workloadIdentityUser to the KSA on the GSA, and finally annotating the KSA with the GSA email address.
To successfully establish GKE Workload Identity, the GCP service account (GSA) and Kubernetes service account (KSA) must first exist. The GSA must be configured with an IAM binding granting roles/iam.workloadIdentityUser to the KSA principal (`serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`). Lastly, the KSA in Kubernetes must be annotated with `iam.gke.io/gcp-service-account=GSA_EMAIL` so the GKE metadata server injects short-lived credentials into Pods running with that KSA.

Step-by-Step Solution

1
Provision target Google Service Account (GSA)
GSA is created in Google Cloud IAM and assigned resource-level roles (e.g., storage.objectViewer).
The GSA provides the Google Cloud permissions needed by the application.
2
Provision Kubernetes Service Account (KSA)
KSA is defined in the target Kubernetes namespace within the GKE cluster.
The KSA establishes the in-cluster identity for the running workload.
3
Establish IAM binding for Workload Identity
The GSA allows the KSA member principal to assume its identity via the roles/iam.workloadIdentityUser IAM role.
Without this IAM binding, Kubernetes service accounts are not authorized to impersonate the GCP service account.
4
Annotate the KSA
The metadata annotation iam.gke.io/gcp-service-account is set on the KSA pointing to the GSA email.
The GKE metadata server reads this annotation to issue temporary GCP identity tokens to Pods using this KSA.

Key Concept

Configuring GKE Workload Identity requires creating both Google and Kubernetes service accounts, granting roles/iam.workloadIdentityUser to link the KSA to the GSA, and annotating the KSA with the GSA email address.
Rate this question

Topics

Configuring Service Account Impersonation and Workload Identity

More questions from this topic