Examkin

Question

Difficulty: HardConfiguring Service Account Impersonation and Workload Identity

A DevOps engineer must configure keyless authentication for a microservice deployed in a Google Kubernetes Engine (GKE) cluster. The microservice runs in the `analytics` namespace and needs to read objects from a Cloud Storage bucket using a Google Service Account (GSA). What is the correct sequence of steps to establish Workload Identity binding between the Kubernetes Service Account (KSA) and the GCP Service Account (GSA)?

  1. 1Create the Google Service Account (GSA) and assign it the Storage Object Viewer role (`roles/storage.objectViewer`) on the target Cloud Storage bucket.
  2. 2Create the Kubernetes Service Account (KSA) in the `analytics` namespace of the GKE cluster.
  3. 3Grant the `roles/iam.workloadIdentityUser` role on the GSA to the principal member formatted as `serviceAccount:PROJECT_ID.svc.id.goog[analytics/KSA_NAME]`.
  4. 4Annotate the KSA with `iam.gke.io/gcp-service-account=GSA_EMAIL` to complete the metadata binding for the GKE pod.

Answer

The correct sequence of steps is: 1) Create the Google Service Account (GSA) and assign it the Storage Object Viewer role on the target bucket, 2) Create the Kubernetes Service Account (KSA) in the `analytics` namespace, 3) Grant the `roles/iam.workloadIdentityUser` role on the GSA to the principal member `serviceAccount:PROJECT_ID.svc.id.goog[analytics/KSA_NAME]`, and 4) Annotate the KSA with `iam.gke.io/gcp-service-account=GSA_EMAIL`.
Establishing Workload Identity requires provisioning the GCP IAM identity (GSA) and Kubernetes identity (KSA), granting `roles/iam.workloadIdentityUser` on the GSA to the KSA principal in the Workload Identity pool (`PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`), and finally annotating the KSA with the GSA email so the GKE metadata server handles token exchanges.

Step-by-Step Solution

1
Provision the Google Service Account (GSA) and grant required GCP resource roles.
A GSA exists with permission to read objects from the target Cloud Storage bucket.
The GSA acts as the GCP IAM identity possessing the necessary permissions on GCP resources.
2
Provision the Kubernetes Service Account (KSA) in the application's GKE namespace.
A KSA identity is registered inside Kubernetes in the `analytics` namespace.
Pods running inside GKE require a local Kubernetes identity to map to GCP IAM.
3
Grant the `roles/iam.workloadIdentityUser` role on the GSA to the KSA member URI.
GCP IAM allows the specific `PROJECT_ID.svc.id.goog[analytics/KSA_NAME]` identity to impersonate the GSA.
This establishes authorization on the GCP side for the GKE Workload Identity pool principal.
4
Annotate the KSA with the metadata key `iam.gke.io/gcp-service-account=GSA_EMAIL`.
The GKE metadata server maps requests from pods using this KSA directly to the target GSA.
This completes the binding on the Kubernetes side so applications automatically acquire short-lived tokens for the GSA without managing JSON key files.

Key Concept

Configuring Workload Identity Binding between GKE KSAs and GCP GSAs
Rate this question

Topics

Configuring Service Account Impersonation and Workload Identity

More questions from this topic