Examkin

Question

Difficulty: MediumConfiguring Service Account Impersonation and Workload Identity

An engineering team is deploying an application to Google Kubernetes Engine (GKE) that requires access to a Google Cloud Storage bucket. To adhere to security best practices, the team decides to use Workload Identity instead of exporting static service account keys. What is the correct sequence of steps to configure Workload Identity binding between the Kubernetes Service Account (KSA) and the GCP Service Account (GSA)?

  1. 1Create a GCP Service Account (GSA) and grant it the required IAM storage permissions on the target bucket.
  2. 2Create a Kubernetes Service Account (KSA) within the specific Kubernetes namespace of your GKE cluster.
  3. 3Grant the Workload Identity User role (roles/iam.workloadIdentityUser) on the GSA to the member 'serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]'.
  4. 4Annotate the KSA with the email address of the GSA using the annotation 'iam.gke.io/gcp-service-account=GSA_EMAIL'.
  5. 5Configure the Pod manifest to use the annotated KSA via the 'serviceAccountName' field and deploy the Pod.

Answer

The correct order to configure Workload Identity is: First, create the GCP Service Account with resource permissions. Second, create the Kubernetes Service Account in the cluster namespace. Third, bind the Workload Identity User role on the GCP Service Account to the Kubernetes Service Account principal. Fourth, annotate the Kubernetes Service Account with the GCP Service Account email. Fifth, configure and deploy the Pod using the annotated Kubernetes Service Account.
The configuration of Workload Identity requires creating the GCP Service Account with access permissions and the Kubernetes Service Account in the cluster, granting the roles/iam.workloadIdentityUser IAM role on the GCP Service Account to the Kubernetes Service Account member URI, annotating the Kubernetes Service Account with the GCP Service Account email, and finally attaching the annotated Kubernetes Service Account to the Pod definition.

Step-by-Step Solution

1
Provision GCP Service Account
GCP Service Account exists with IAM bucket permissions.
Resource permissions must belong to a Google Cloud identity that will be impersonated.
2
Provision Kubernetes Service Account
KSA created in GKE namespace.
Workload Identity maps a specific Kubernetes Service Account to a GCP Service Account.
3
Allow KSA to impersonate GSA via IAM
roles/iam.workloadIdentityUser assigned to serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME].
Without this IAM role assignment, GCP IAM blocks the Workload Identity impersonation attempt.
4
Annotate KSA with GSA email
KSA includes annotation iam.gke.io/gcp-service-account=GSA_EMAIL.
The annotation tells the GKE Metadata Server which GSA tokens to issue when the workload requests credentials.
5
Deploy Pod with KSA reference
Pod runs using the annotated service account and obtains GCP access transparently.
Setting serviceAccountName in the Pod spec ties the pod execution to the configured Workload Identity mapping.

Key Concept

Workload Identity allows GKE workloads to impersonate a GCP Service Account by binding the roles/iam.workloadIdentityUser role to the Kubernetes Service Account identity string and annotating the KSA.
Rate this question

Topics

Configuring Service Account Impersonation and Workload Identity

More questions from this topic