Examkin

Question

Difficulty: HardConfiguring Service Account Impersonation and Workload Identity

What is the correct sequential order of steps required to configure GKE Workload Identity so that an application running in a Kubernetes namespace can access Google Cloud resources using a dedicated Google Service Account (GSA) without relying on static service account keys?

  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 specific IAM roles required for the target GCP resources.
  3. 3Create a Kubernetes Service Account (KSA) in the dedicated GKE namespace where the workload resides.
  4. 4Grant the `roles/iam.workloadIdentityUser` role on the GSA to the KSA member identity (`serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`).
  5. 5Annotate the Kubernetes Service Account with `iam.gke.io/gcp-service-account=GSA_EMAIL` to link the KSA to the GSA.

Answer

The correct sequence starts with enabling Workload Identity on the GKE cluster, followed by creating and granting IAM roles to the Google Service Account (GSA). Next, create the Kubernetes Service Account (KSA), grant the `roles/iam.workloadIdentityUser` role on the GSA to the KSA identity URI, and finally annotate the KSA with the GSA's email address.
Configuring Workload Identity follows a logical top-down sequence: infrastructure setup, identity provisioning on both GCP and Kubernetes layers, authorization via IAM binding, and pod configuration via KSA annotation. First, the GKE cluster must have Workload Identity enabled to create the workload identity pool. Second, the Google Service Account (GSA) is created and assigned resource permissions. Third, the Kubernetes Service Account (KSA) is created in the target namespace. Fourth, the IAM role `roles/iam.workloadIdentityUser` is granted on the GSA to the formatted KSA member URI. Finally, the KSA is annotated with the GSA email so the GKE metadata server handles keyless token negotiation.

Step-by-Step Solution

1
Enable Workload Identity at the cluster level.
The GKE cluster establishes a workload identity pool (`PROJECT_ID.svc.id.goog`) and enables the GKE metadata server daemonset on cluster nodes.
Workload Identity infrastructure must be active before identity delegation can take place.
2
Configure the target Google Service Account (GSA).
A GSA is provisioned in Google Cloud IAM with resource access permissions following the principle of least privilege.
The GSA provides the Google Cloud identity that performs actual operations against GCP APIs.
3
Provision the Kubernetes Service Account (KSA).
A KSA object exists in the target Kubernetes namespace.
The KSA provides the pod-level workload identity within Kubernetes.
4
Bind the KSA identity to the GSA using IAM permissions.
The KSA identity string `serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]` receives the `roles/iam.workloadIdentityUser` role on the GSA.
This step grants permission for the specific Kubernetes service account to impersonate the target GSA.
5
Annotate the KSA with the GSA email address.
Pods using the KSA are automatically intercepted by the GKE metadata server to exchange Kubernetes tokens for short-lived GCP OAuth tokens.
The annotation completes the mapping between the Kubernetes workload and the GCP service account identity.

Key Concept

GKE Workload Identity Configuration Sequence
Rate this question

Topics

Configuring Service Account Impersonation and Workload Identity

More questions from this topic