Workload identity federation in GCP - Commands & Configuration

Introduction

Workload identity federation lets your applications outside Google Cloud securely access Google Cloud resources without using long-lived service account keys. It solves the problem of managing and rotating keys by using trusted identity providers instead.

When you run applications on AWS or Azure and want them to access Google Cloud Storage without storing service account keys.

When you have on-premises servers that need to access Google Cloud BigQuery securely.

When you want to avoid managing service account keys for security reasons.

When you want to use short-lived credentials issued dynamically for Google Cloud access.

When you want to simplify authentication for CI/CD pipelines running outside Google Cloud.

Config File - workload_identity_pool.yaml

workload_identity_pool.yaml

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMWorkloadIdentityPool
metadata:
  name: example-pool
  namespace: gcp-resources
spec:
  description: "Example workload identity pool for external identities"
  disabled: false
  displayName: "Example Pool"
  location: global
---
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMWorkloadIdentityPoolProvider
metadata:
  name: example-provider
  namespace: gcp-resources
spec:
  workloadIdentityPoolRef:
    name: example-pool
  displayName: "Example Provider"
  description: "OIDC provider for external identities"
  oidc:
    issuerUri: https://accounts.google.com
  attributeMapping:
    "google.subject": "assertion.sub"
    "attribute.actor": "assertion.actor"
    "attribute.aud": "assertion.aud"

This YAML file creates a Workload Identity Pool named example-pool which acts as a container for external identities. It also creates a Workload Identity Pool Provider named example-provider that connects the pool to an external OpenID Connect (OIDC) identity provider, here Google Accounts. The attributeMapping maps claims from the external identity token to Google Cloud attributes used for authentication.

Commands

This command creates the workload identity pool and provider in Google Cloud using Config Connector. It sets up the trust relationship with the external identity provider.

Terminal

kubectl apply -f workload_identity_pool.yaml

Expected Output

iamworkloadidentitypool.iam.cnrm.cloud.google.com/example-pool created

iamworkloadidentitypoolprovider.iam.cnrm.cloud.google.com/example-provider created

This command grants the workload identity pool permission to impersonate the Google Cloud service account named example-sa. This allows external identities from the pool to access resources as this service account.

Terminal

gcloud iam service-accounts add-iam-policy-binding [e-mail] --role roles/iam.workloadIdentityUser --member "principalSet://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/example-pool/*"

Expected Output

Updated IAM policy for serviceAccount [[e-mail]].

→

--role - Specifies the IAM role to grant

→

--member - Specifies the identity or group to grant the role

This command uses an external identity token file to authenticate as the workload identity user. It obtains short-lived credentials to access Google Cloud resources.

Terminal

gcloud auth login --brief --cred-file=external-identity-token.json

Expected Output

Activated service account credentials for: [[e-mail]]

→

--cred-file - Specifies the external identity token file to use

This command lists the storage buckets in the project using the authenticated credentials from workload identity federation.

Terminal

gcloud storage buckets list --project=my-project

Expected Output

NAME                LOCATION          STORAGE CLASS

example-bucket       US               STANDARD

→

--project - Specifies the Google Cloud project to list buckets from

Key Concept

If you remember nothing else from this pattern, remember: workload identity federation lets external apps securely access Google Cloud without storing service account keys by trusting external identities.

Common Mistakes

Not granting the workload identity pool permission to impersonate the service account.

Without this permission, external identities cannot access Google Cloud resources as the service account.

Use gcloud iam service-accounts add-iam-policy-binding to grant roles/iam.workloadIdentityUser to the workload identity pool.

Using expired or invalid external identity tokens for authentication.

Authentication will fail because tokens must be valid and trusted by the workload identity provider.

Ensure tokens are fresh and issued by the configured external identity provider.

Misconfiguring attribute mappings in the workload identity pool provider.

Incorrect mappings prevent Google Cloud from recognizing external identities properly.

Map external token claims correctly to Google attributes like google.subject.

Summary

Create a workload identity pool and provider to trust external identities.

Grant the pool permission to impersonate a Google Cloud service account.

Authenticate using external identity tokens to get short-lived credentials.

Use these credentials to access Google Cloud resources securely.

Practice

1. What is the main purpose of Workload Identity Federation in Google Cloud?

easy

A. Encrypt data stored in Google Cloud Storage

B. Create virtual machines automatically

C. Manage billing accounts for Google Cloud projects

D. Allow external applications to access Google Cloud without using long-lived keys

Solution

1. Step 1: Understand Workload Identity Federation purpose

   It is designed to let external apps access Google Cloud resources securely without needing to manage long-lived service account keys.

2. Step 2: Compare options with this purpose

   Only Allow external applications to access Google Cloud without using long-lived keys matches this purpose. Other options describe unrelated Google Cloud features.

3. Final Answer:

   Allow external applications to access Google Cloud without using long-lived keys -> Option D

4. Quick Check:

   Workload Identity Federation = Access without keys [OK]

Hint: Remember: federation means access without keys [OK]

Common Mistakes:

• Confusing federation with VM creation
• Thinking it manages billing
• Assuming it encrypts storage data

2. Which of the following is the correct way to create a workload identity pool using gcloud CLI?

easy

A. gcloud iam service-accounts create POOL_ID --project=my-project

B. gcloud iam workload-identity-pools create POOL_ID --location=global

C. gcloud compute instances create POOL_ID --zone=global

D. gcloud storage buckets create POOL_ID --location=global

Solution

1. Step 1: Identify the correct gcloud command for workload identity pools

   The command to create a workload identity pool is under 'gcloud iam workload-identity-pools create' with a pool ID and location.

2. Step 2: Check each option

   gcloud iam workload-identity-pools create POOL_ID --location=global matches the correct syntax. Options A, B, and D relate to other services like service accounts, compute instances, and storage buckets.

3. Final Answer:

   gcloud iam workload-identity-pools create POOL_ID --location=global -> Option B

4. Quick Check:

   Workload identity pool creation uses 'gcloud iam workload-identity-pools create' [OK]

Hint: Look for 'iam workload-identity-pools create' command [OK]

Common Mistakes:

• Using compute or storage commands instead
• Confusing service account creation with pool creation
• Missing the --location flag

3. Given this snippet to configure a workload identity provider:

gcloud iam workload-identity-pools providers create-oidc my-provider \
  --workload-identity-pool=my-pool \
  --issuer-uri=https://accounts.example.com \
  --allowed-audiences=example-audience

What is the expected behavior after this command?

medium

A. It creates an OIDC provider in the specified pool trusting identities from the issuer URI

B. It deletes the workload identity pool named my-pool

C. It creates a service account named my-provider

D. It sets IAM permissions for the service account

Solution

1. Step 1: Analyze the command purpose

   The command creates an OIDC identity provider inside a workload identity pool, specifying the issuer URI and allowed audiences.

2. Step 2: Match behavior to options

   It creates an OIDC provider in the specified pool trusting identities from the issuer URI correctly describes creating a provider trusting external identities. Other options describe unrelated actions.

3. Final Answer:

   It creates an OIDC provider in the specified pool trusting identities from the issuer URI -> Option A

4. Quick Check:

   Provider creation = trust external issuer [OK]

Hint: OIDC provider means trusting external issuer [OK]

Common Mistakes:

• Thinking it deletes pools
• Confusing provider with service account creation
• Assuming it sets IAM permissions directly

4. You run this command to grant an external identity access to a service account:

gcloud iam service-accounts add-iam-policy-binding [e-mail] \
  --role roles/iam.workloadIdentityUser \
  --member "principalSet://iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/my-pool/attribute.subject/my-app"

But the external app still cannot access the service account. What is the most likely error?

medium

A. The service account does not exist

B. The role roles/iam.workloadIdentityUser is invalid

C. The member string format is incorrect or does not match the external identity

D. The workload identity pool was deleted

Solution

1. Step 1: Check the member string format

   The member string must exactly match the external identity's attributes. A mismatch or typo will block access.

2. Step 2: Verify other options

   The service account likely exists if the command ran. The role is valid. Pool deletion would cause different errors.

3. Final Answer:

   The member string format is incorrect or does not match the external identity -> Option C

4. Quick Check:

   Member string must match identity exactly [OK]

Hint: Check member string matches external identity exactly [OK]

Common Mistakes:

• Using wrong member string format
• Assuming role is invalid
• Ignoring pool existence

5. You want to allow an external CI/CD system to deploy to your Google Cloud project using workload identity federation. Which combination of steps is required to set this up securely?

hard

A. Create a workload identity pool and provider for the CI/CD system, then grant the provider access to a service account with minimal roles

B. Create a service account key and share it with the CI/CD system, then assign owner role to the service account

C. Create a VM instance and install the CI/CD system there with full project permissions

D. Enable billing API and assign billing admin role to the CI/CD system

Solution

1. Step 1: Create workload identity pool and provider

   This lets the external CI/CD system authenticate without keys by trusting its identity.

2. Step 2: Grant minimal permissions to a service account

   Assign only needed roles to the service account and allow the provider to impersonate it, following least privilege.

3. Final Answer:

   Create a workload identity pool and provider for the CI/CD system, then grant the provider access to a service account with minimal roles -> Option A

4. Quick Check:

   Use federation + minimal roles for secure access [OK]

Hint: Use federation and least privilege roles [OK]

Common Mistakes:

• Sharing long-lived keys
• Assigning overly broad roles
• Using VM instead of federation
• Confusing billing roles with access