Workload Identity in Practice

In this tutorial, we’re going to go through the Workload Identity feature and see how it helps to improve the way we manage access to Google Services and APIs from applications running in Google Kubernetes Engine (GKE).

Workload Identity is the recommended way to access Google Cloud APIs from within GKE due to its improved security properties and manageability. With Workload Identity you can control access to APIs using Google service accounts and IAM roles without deploying static service account JSON keys to Pods and without relying on the node’s service account.

Create a GKE Cluster

Let’s get started.

Assuming you already have a GCP project, create a variable with the name of your project and two other variables for cluster name and region.


gcloud config set project $gcp_project

Start creating a simple cluster with Workload Identity enabled, which is defined with the property --workload-pool.

gcloud beta container clusters create ${cluster_name} \
  --release-channel regular \
  --enable-ip-alias \
  --region $cluster_region \

Get cluster credentials:

gcloud container clusters get-credentials $cluster_name --region $cluster_region

Configure Workload Identity

With Workload Identity, you configure a Kubernetes service account (KSA) to act as a Google service account (GSA). Any workload running as the KSA, automatically authenticates as the GSA when accessing Google Cloud APIs.

Let’s create a Google Service Account:

gcloud iam service-accounts create le-application-stg

Now we create a k8s namespace and k8s service account:

kubectl create namespace staging

kubectl create serviceaccount le-application -n staging

A note on Kubernetes Declarative Configuration

In this tutorial, we are using the kubectl CLI to create and annotate the namespace and service account, and to run Pods. The purpose is to play around and quickly evaluate how Workload Identity works. In the real world you’ll likely want to use YAML configuration to declaratively manage your Kubernetes resources.

Associate both SAs using an IAM Policy binding:

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:${gcp_project}[staging/le-application]" \

And, finally, annotate your service account:

kubectl annotate serviceaccount \
  le-application \${gcp_project} \
  -n staging

Validate the config

The workload identity configuration is in place and we are ready to use it. First, we’ll create a Google Cloud Storage (GCS) bucket and upload a file.

gsutil mb -p $gcp_project gs://le-application-stg/
echo foo > my_application_file
gsutil cp my_application_file gs://le-application-stg/

Now let’s run a Pod and try to download the file from the GCS bucket just created:

kubectl run -it --rm --restart=Never \
  --serviceaccount le-application \
  --image google/cloud-sdk:slim bb8 -n staging

root@bb8:/ gsutil cp gs://le-application-stg/my_application_file .
AccessDeniedException: 403 does not have storage.objects.list access to the Google Cloud Storage bucket.

It fails. To fix it we grant the GSA access to the bucket:

gsutil iam ch serviceAccount:le-application-stg@${gcp_project} gs://le-application-stg/

From now on, we manage access to services and APIs using the GSA and Google IAM and in Kubernetes we grant access to applications using the KSA.

Run again and verify:

kubectl run -it --rm --image google/cloud-sdk:slim bb8 --serviceaccount le-application -n staging --restart=Never
root@bb8:/ gsutil cp gs://le-application-stg/my_application_file .
root@bb8:/ cat my_application_file

Clean up

gsutil rm -r gs://le-application-stg
gcloud iam service-accounts delete le-application-stg@${gcp_project}
gcloud container clusters delete $cluster_name --region $cluster_region

Next Steps

If you liked this content you might be interested to check my tutorial Restrict Google Kubernetes Engine Workload Identity with Kyverno on the Google Cloud Community tutorials.