Examkin

Question

Difficulty: Very hardConfiguring Service Account Impersonation and Workload Identity

A Cloud Engineer is tasked with establishing passwordless, keyless authentication for a pod running in a Google Kubernetes Engine (GKE) cluster to query BigQuery tables. The team has mandated using GKE Workload Identity following Google Cloud best practices. In what precise sequence should the engineer execute the configuration steps to enable this access?

  1. 1Enable Workload Identity on the GKE cluster to establish the workload identity pool for the Google Cloud project.
  2. 2Create a Google Service Account (GSA) and grant it the BigQuery Data Viewer IAM role on the target project.
  3. 3Create a Kubernetes Service Account (KSA) inside the specific Kubernetes namespace where the application workload resides.
  4. 4Add an IAM policy binding granting the Workload Identity User role (roles/iam.workloadIdentityUser) on the GSA to the KSA's principal member URI.
  5. 5Annotate the Kubernetes Service Account (KSA) with the email address of the Google Service Account (GSA).

Answer

The correct sequence starts with enabling Workload Identity on the GKE cluster, creating and granting permissions to the Google Service Account (GSA), creating the Kubernetes Service Account (KSA) in the namespace, granting the Workload Identity User role on the GSA to the KSA member URI, and finally annotating the KSA with the GSA email.
The proper deployment flow for GKE Workload Identity requires infrastructure enablement first (enabling Workload Identity on the cluster), establishing both identity endpoints (GSA with BigQuery permissions and KSA in the namespace), authorizing the relationship in IAM (granting roles/iam.workloadIdentityUser on the GSA to the KSA principal URI), and completing the in-cluster mapping (annotating the KSA with the GSA email).

Step-by-Step Solution

1
Enable cluster Workload Identity pool
GKE configures the Workload Identity pool URI (PROJECT_ID.svc.id.goog) for pod identity translation.
Without enabling the feature on the cluster, GKE Metadata Server cannot intercept token requests.
2
Provision GSA with target IAM roles
The GSA possesses GCP resource access rights (BigQuery Data Viewer).
Identity delegation requires an existing target GCP identity that holds the necessary workload permissions.
3
Provision KSA within the Kubernetes namespace
A namespace-scoped KSA object is available in Kubernetes.
The KSA forms the subject reference in the Workload Identity pool URI.
4
Bind roles/iam.workloadIdentityUser on GSA to KSA identity URI
GCP IAM authorizes the KSA principal (serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]) to impersonate the GSA.
IAM policy must explicitly allow the external Kubernetes service account identity to assume the GSA identity.
5
Annotate KSA with iam.gke.io/gcp-service-account key
Pods using this KSA automatically receive GSA tokens from the GKE Metadata Server.
The annotation triggers the cluster metadata service to map pod calls to the designated GSA.

Key Concept

GKE Workload Identity binding procedure
Rate this question

Topics

Configuring Service Account Impersonation and Workload Identity

More questions from this topic