7.2 Workload Identity Federation, Service Account Impersonation & IAP

Workload Identity Federation, Service Account Impersonation & IAP

Zero-Trust Paradigm: Modern cloud security models reject static perimeter defenses and long-lived private key secrets. Google Cloud implements the BeyondCorp Zero-Trust Architecture, replacing long-lived credentials with short-lived tokens and shifting access controls from network-level perimeters (VPNs, bastion hosts) to dynamic identity- and context-aware gateways. Architects must design workload authentication flows that eliminate static service account keys and enforce seamless, audited access across multi-cloud and container environments.

---

Workload Identity Federation (WIF) Architecture

Historically, external workloads running in Amazon Web Services (AWS), Microsoft Azure, on-premises datacenters, or CI/CD pipelines (GitHub Actions, GitLab CI/CD) accessed Google Cloud APIs by downloading and storing long-lived service account private JSON keys. This practice introduced massive risks: keys leaked into git repositories, were improperly shared across teams, and lacked automated rotation.

Workload Identity Federation (WIF) completely eliminates static keys by establishing a federated trust relationship between Google Cloud and external Identity Providers (IdPs).

+-----------------------------------------------------------------------------------------+
|                       WORKLOAD IDENTITY FEDERATION TOKEN FLOW                           |
|                                                                                         |
|  +-------------------+                                                                  |
|  | External Workload | (1) Obtains external token (AWS SigV4, Azure OAuth, OIDC JWT)    |
|  | (GitHub Actions / |                                                                  |
|  | AWS EC2 / On-Prem)| -------------------------\                                       |
|  +-------------------+                           \ (2) STS Token Exchange               |
|                                                   v                                     |
|                                    +------------------------------+                     |
|                                    | Security Token Service (STS) |                     |
|                                    |  - Validates Issuer Signature|                     |
|                                    |  - Evaluates Attribute Maps  |                     |
|                                    |  - Checks Attribute Condition|                     |
|                                    +------------------------------+                     |
|                                                   |                                     |
|                                                   | (3) Returns Federated STS Token     |
|                                                   v                                     |
|  +---------------------+           +------------------------------+                     |
|  | Target GCP Resource | <======== | IAM Credentials API          |                     |
|  | (Cloud Storage /    |   (5) API | (4) Impersonates target GSA  |                     |
|  | BigQuery / GKE)     |   Request |     via roles/iam.           |                     |
|  +---------------------+           |     workloadIdentityUser     |                     |
|                                    +------------------------------+                     |
+-----------------------------------------------------------------------------------------+

Core Components of Workload Identity Federation

1. Workload Identity Pool: An entity that manages external identities (e.g., projects/[NUM]/locations/global/workloadIdentityPools/github-pool). Organizations typically deploy dedicated pools per environment or external cloud.
2. Workload Identity Provider: Describes the relationship between Google Cloud and the external IdP. Supports:
   • AWS: Uses AWS Security Token Service (STS) GetCallerIdentity signed requests.
   • Azure AD / Microsoft Entra ID: Uses Azure OAuth 2.0 OIDC tokens.
   • OpenID Connect (OIDC): For GitHub Actions, GitLab CI/CD, Terraform Cloud, Kubernetes clusters, and Okta.
   • SAML 2.0: For enterprise identity systems (PingFederate, Active Directory Federation Services).
3. Attribute Mapping & Attribute Conditions:
   • Attribute Mapping: Maps external token claims to Google Cloud STS attributes (e.g., google.subject = assertion.sub, attribute.repository = assertion.repository).
   • Attribute Condition: A CEL expression that restricts which external identities can exchange tokens (e.g., assertion.repository == 'corp-org/payments-service' && assertion.ref == 'refs/heads/main').
4. Service Account Impersonation Binding: The federated principal is granted roles/iam.workloadIdentityUser on the target Google Service Account (GSA):

# Binding federated GitHub identity to target Google Service Account
gcloud iam service-accounts add-iam-policy-binding \
    deployer-gsa@my-prod-project.iam.gserviceaccount.com \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/github-pool/attribute.repository/corp-org/payments-service"

---

GKE Workload Identity: Native Kubernetes Secretless Access

In containerized environments, container Pods running inside Google Kubernetes Engine (GKE) frequently require access to Google Cloud APIs (Cloud Storage, BigQuery, Cloud Spanner, Pub/Sub). Legacy approaches mounted static service account key files into Pod volumes or relied on broad Compute Engine node-level service accounts.

GKE Workload Identity is the recommended best practice that binds a Kubernetes Service Account (KSA) directly to a Google Service Account (GSA).

+-----------------------------------------------------------------------------------------+
|                              GKE WORKLOAD IDENTITY TOPOLOGY                             |
|                                                                                         |
|  +-----------------------------------------------------------------------------------+  |
|  | GKE CLUSTER (VPC-Native)                                                          |  |
|  |                                                                                   |  |
|  |  +---------------------------+             +-----------------------------------+  |  |
|  |  | Pod (Namespace: payments) |             | GKE Node VM                       |  |
|  |  | KSA: sa-payment-processor |             | GKE Metadata Server (DaemonSet)   |  |
|  |  |                           |             | (Interception: 169.254.169.254)   |  |
|  |  | 1. Requests Token         | ----------> |                                   |  |
|  |  | 4. Receives OAuth Token   | <---------- | 2. Verifies KSA JWT Token         |  |
|  |  +---------------------------+             | 3. Exchanges for GSA Token via STS|  |
|  |                |                           +-----------------------------------+  |  |
|  +----------------|---------------------------------------------|--------------------+  |
|                   |                                             |                       |
|                   v (5. Authenticated API Call)                 v                       |
|  +-----------------------------------------------------------------------------------+  |
|  | Google Cloud API: Cloud Spanner (Authorized via sa-payment-gsa@project.iam...)    |  |
|  +-----------------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------------+

Step-by-Step GKE Workload Identity Implementation

1. Enable Workload Identity on Cluster & Node Pool:

   gcloud container clusters update prod-cluster \
       --workload-pool=my-project-id.svc.id.goog
   

2. Create the Google Service Account (GSA):

   gcloud iam service-accounts create sa-payment-gsa --project=my-project-id
   

3. Grant IAM Roles to the GSA:

   gcloud projects add-iam-policy-binding my-project-id \
       --member="serviceAccount:sa-payment-gsa@my-project-id.iam.gserviceaccount.com" \
       --role="roles/spanner.databaseUser"
   

4. Bind the KSA to the GSA with roles/iam.workloadIdentityUser:

   gcloud iam service-accounts add-iam-policy-binding \
       sa-payment-gsa@my-project-id.iam.gserviceaccount.com \
       --role="roles/iam.workloadIdentityUser" \
       --member="principal://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/my-project-id.svc.id.goog/subject/ns/payments/sa/sa-payment-processor"
   

5. Annotate the Kubernetes Service Account (KSA):

   kubectl annotate serviceaccount sa-payment-processor \
       --namespace payments \
       iam.gke.io/gcp-service-account=sa-payment-gsa@my-project-id.iam.gserviceaccount.com
   

---

Service Account Impersonation & Short-Lived Credential Minting

Service Account Impersonation allows an authorized human user, automated process, or peer service account to temporarily assume the identity of a target service account to mint short-lived credentials.

Impersonation Mechanics & Credential Types

To authorize impersonation, grant the principal the Service Account Token Creator (roles/iam.serviceAccountTokenCreator) role on the target service account resource.

+-----------------------------------------------------------------------------------------+
|                     SHORT-LIVED CREDENTIAL TYPES VIA IAM CREDENTIALS API                |
+-----------------------------------------------------------------------------------------+
|  1. OAUTH 2.0 ACCESS TOKENS (GenerateAccessToken)                                      |
|     - Short-lived bearer token (default 1 hour, max 12 hours via Org Policy).           |
|     - Used for direct Google Cloud REST/gRPC API calls and Google Cloud CLI (gcloud).   |
+-----------------------------------------------------------------------------------------+
|  2. OPENID CONNECT (OIDC) ID TOKENS (GenerateIdToken)                                   |
|     - Cryptographically signed JWT tokens with specified audience (target service URL). |
|     - Used to authenticate requests to Cloud Run, Cloud Functions, and IAP apps.        |
+-----------------------------------------------------------------------------------------+
|  3. SIGNED URLS & SIGNED BLOBS (SignBlob / SignJwt)                                     |
|     - Delegated, time-limited cryptographic signatures for Cloud Storage operations.    |
|     - Allows external users to upload/download objects without GCP accounts.            |
+-----------------------------------------------------------------------------------------+

Break-Glass Governance & Non-Repudiable Auditability

When a human administrator executes API calls via a downloaded static JSON key, Cloud Audit Logs records only the Service Account identity—the true human actor is completely masked.

In contrast, when a user impersonates a service account, Cloud Audit Logs captures both identities in protoPayload.authenticationInfo.serviceAccountDelegationInfo:

• First-Party Principal Subject: alice@example.com (the authenticated human).
• Impersonated Service Account: sa-prod-deployer@project.iam.gserviceaccount.com. This ensures complete non-repudiation, satisfying SOX, HIPAA, and PCI-DSS compliance audits.

# Human developer executing gcloud commands via impersonation without storing keys
gcloud compute instances list \
    --impersonate-service-account=sa-prod-viewer@my-project.iam.gserviceaccount.com

---

Identity-Aware Proxy (IAP): Zero-Trust Infrastructure & Web Access

Identity-Aware Proxy (IAP) establishes a central, context-aware authorization layer in front of web applications and VM administrative interfaces, enforcing Google's BeyondCorp architecture.

+-----------------------------------------------------------------------------------------+
|                             IDENTITY-AWARE PROXY ARCHITECTURE                           |
|                                                                                         |
|  +------------------+                                                                   |
|  | User / Admin     | (1) HTTPS Request / SSH Tunnel Initiation                         |
|  | (Remote Laptop)  | -------------------------\                                        |
|  +------------------+                           \                                       |
|                                                  v                                      |
|                                    +----------------------------------+                 |
|                                    | Identity-Aware Proxy (IAP)       |                 |
|                                    |  - Authenticates Identity (IdP)  |                 |
|                                    |  - Checks Access Context Manager |                 |
|                                    |    (Device state, Geofence, IP)  |                 |
|                                    |  - Evaluates IAM Permissions     |                 |
|                                    +----------------------------------+                 |
|                                             /                \                          |
|                       HTTPS Web Traffic    /                  \  TCP Forwarding Tunnel  |
|                                           v                    v (Port 22/3389)         |
|                            +--------------------+        +--------------------+         |
|                            | External App LB    |        | Internal VM        |         |
|                            | Backend: Cloud Run |        | (No Public IP)     |         |
|                            | / GCE Instance Grp |        | Firewall: Ingress  |         |
|                            +--------------------+        | 35.235.240.0/20    |         |
|                                                          +--------------------+         |
+-----------------------------------------------------------------------------------------+

1. IAP for HTTPS Web Applications

• Intercepts incoming web traffic to External and Internal Application Load Balancers.
• Validates user identity and evaluates Access Context Manager (ACM) policies (e.g., corporately managed device, specific geofence, corporate IP subnet).
• Cryptographically signs identity headers and passes them to backend services:
  • X-Goog-Authenticated-User-Email: Email address of the authenticated principal.
  • X-Goog-IAP-JWT-Assertion: Signed JSON Web Token enabling backends to cryptographically verify that requests passed through IAP without tampering.

2. IAP TCP Forwarding (Tunneling): Eliminating Bastion Hosts

Traditional cloud environments rely on public-facing bastion hosts (jump boxes) to provide SSH (port 22) and RDP (port 3389) access to internal virtual machines. Bastion hosts represent significant security overhead: they require public IP addresses, OS patching, DDoS protection, and SSH key rotation.

IAP TCP Forwarding completely eliminates bastion hosts:

• Administrators connect to private internal VMs over an encrypted WebSocket tunnel routed directly through Google's infrastructure.
• Target VMs require no public IP address.
• IAM Role required: IAP-Secured Tunnel User (roles/iap.tunnelResourceAccessor).
• Firewall Requirement: A single VPC ingress firewall rule must allow TCP ports 22 and 3389 from Google's dedicated IAP netblock: 35.235.240.0/20.

# Connecting to an internal VM with zero public IP via IAP TCP tunnel
gcloud compute ssh my-internal-vm \
    --zone=us-central1-a \
    --tunnel-through-iap

---

Concrete Architectural Scenario: Secure Multi-Cloud CI/CD & Production Access

Scenario Profile

• Enterprise: E-Commerce retailer with microservices deployed on GKE and development pipelines hosted on GitHub Actions.
• Requirements:
  1. GitHub Actions must deploy container images to Google Artifact Registry and trigger rolling updates on GKE without managing GCP service account keys in GitHub Secrets.
  2. Pods running inside GKE must query Cloud Spanner without storing database passwords or GCP key files inside Kubernetes Secrets.
  3. Site Reliability Engineers (SREs) must be able to SSH into backend worker VMs for debugging without exposing VMs to the public internet or managing bastion hosts.

Solution Blueprint

1. Workload Identity Federation for GitHub Actions:
   • Create a Workload Identity Pool github-pool and OIDC Provider for https://token.actions.githubusercontent.com.
   • Configure attribute mapping for attribute.repository = assertion.repository.
   • Bind sa-cicd-deployer@project.iam... to principalSet://.../attribute.repository/my-org/storefront-app with roles/artifactregistry.writer and roles/container.developer.
2. GKE Workload Identity for Microservices:
   • Enable Workload Identity on the GKE cluster.
   • Bind Kubernetes Service Account sa-orders-processor in namespace orders to Google Service Account sa-spanner-orders@project.iam... with roles/spanner.databaseUser.
   • Annotate sa-orders-processor with the GSA email. Pods query the GKE metadata server natively.
3. IAP TCP Tunneling for SRE Access:
   • Remove all public external IP addresses from Compute Engine worker instances.
   • Create a VPC ingress firewall rule allowing TCP port 22 from source CIDR 35.235.240.0/20.
   • Grant SREs roles/iap.tunnelResourceAccessor and roles/compute.osAdminLogin. SREs execute gcloud compute ssh [VM] --tunnel-through-iap.

---

[!IMPORTANT] Exam Watch: For the Google Cloud Architect exam, whenever an external CI/CD tool (GitHub Actions, GitLab) or external cloud (AWS, Azure) needs to authenticate to Google Cloud, Workload Identity Federation is always the correct, keyless architectural choice. For GKE workloads accessing Google APIs, GKE Workload Identity is mandatory. If a question asks how to provide SSH/RDP access to private VMs without bastion hosts and without public IPs, choose IAP TCP Forwarding with a firewall rule permitting 35.235.240.0/20.

---

Secure Remote Access: Adding Chrome Enterprise Premium

Blueprint section 3.1 enumerates secure remote access patterns for workforces: Identity-Aware Proxy and service account impersonation (covered above) are joined by Chrome Enterprise Premium, which delivers Zero Trust, browser-based access for employees and contractors:

• Context-Aware Access: grant access to web applications and Google Cloud resources based on user identity and device posture (managed device, encryption, OS patch level, location) without a traditional VPN — the BeyondCorp model.
• Data loss prevention in the browser: controls such as restricting copy/paste, downloads, and uploads for sensitive SaaS and cloud consoles reduce exfiltration risk from unmanaged endpoints.
• Threat and data protection: Safe Browsing integration and malware scanning protect users reaching corporate resources from potentially compromised devices.

Exam trigger: when a scenario requires contractor or BYOD access to internal web applications without deploying VPN clients or bastion hosts — with device-posture conditions — the answer is Chrome Enterprise Premium with Context-Aware Access, complementing IAP TCP forwarding for administrative SSH/RDP flows.