Setting Up GKE Workload Identity

Workload identification allows applications, services, or scripts (collectively referred to as "workloads") to authenticate and access resources residing in cloud-based platforms using short-lived, automatically managed credentials.

For instance, in Google Cloud, Workload Identity Federation allows external workloads (e.g., those running on AWS, Azure, or on-premises) to access Google Cloud resources without service account keys.

This guide walks you through setting up Workload Identity in Google Kubernetes Engine (GKE) by:

• Creating a Google Cloud IAM Service Account (GSA)
• Creating a Kubernetes Service Account (KSA)
• Binding the KSA to the GSA using the iam.gke.io/gcp-service-account annotation
• Deploying a sample pod that uses the identity

Prerequisites

Before you begin, ensure you have the following:

• A GCP project with billing enabled
• A GKE cluster with Workload Identity enabled
• gcloud CLI installed and authenticated
• kubectl configured to access your GKE cluster

Step 1: Set variables

Set your environment variables:

export PROJECT_ID="your-gcp-project-id" export CLUSTER_NAME="your-gke-cluster-name" export CLUSTER_ZONE="your-cluster-zone" export GSA_NAME="gke-container-inspector-sa" export KSA_NAME="anzo-operator" export NAMESPACE="default"

Step 2: Create a Google Cloud Service Account (GSA)

gcloud iam service-accounts create $GSA_NAME \ --project=$PROJECT_ID \ --description="GSA for GKE Workload Identity" \ --display-name="GKE Workload Identity"

Step 3: Grant Identity and Access Management (IAM) Permissions to the GSA

Give the GSA the necessary IAM roles. For example, to access Google Cloud Storage:

gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:$GSA_NAME@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/storage.objectViewer"

gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:S$GSA_NAME@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/artifactregistry.reader"

gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:$GSA_NAME@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/containeranalysis.notes.viewer"

Adjust the role as per your workload needs.

Step 4: Enable Workload Identity on the GKE Cluster

Ensure that Workload Identity is enabled on your GKE cluster. You can enable it by updating your cluster:

gcloud container clusters update $CLUSTER_NAME \ --zone $CLUSTER_ZONE \ --workload-pool="$PROJECT_ID.svc.id.goog"

This configures your cluster to use the workload pool associated with your project.

Step 5: Create a Kubernetes Service Account (KSA)

Create a KSA in your desired namespace (e.g., default):

kubectl create serviceaccount $KSA_NAME --namespace $NAMESPACE

This service account will be used by your GKE workloads (pods).

Step 6: Annotate the KSA with the GSA

To allow the KSA to impersonate the GSA, annotate the KSA with the GSA’s email:

kubectl annotate serviceaccount \ --namespace $NAMESPACE \ $KSA_NAME \ iam.gke.io/gcp-service-account=$GSA_NAME@$PROJECT_ID.iam.gserviceaccount.com

This annotation tells GKE to use the specified GCP service account when the workload uses this KSA.