8.2 Workload Identity and Service Authentication

Application Identity, Workload Identity & Secret Manager

In modern cloud architectures, securing application communication requires replacing static perimeter defenses and embedded credentials with dynamic, cryptographically verifiable identities. The Google Cloud Professional Cloud Developer exam emphasizes the elimination of long-lived service account keys, the configuration of Workload Identity across container platforms, fine-grained credential injection with Secret Manager, and zero-trust perimeter verification using Identity-Aware Proxy (IAP).

---

Google Cloud Service Accounts & Token Mechanics

A Service Account (SA) is a special Google identity used by applications and virtual workloads rather than individual human end-users. Workloads use service accounts to authenticate against Google Cloud APIs.

Service Account Classifications

1. User-Managed Service Accounts: Created explicitly by developers (e.g., order-service@my-project.iam.gserviceaccount.com). Best practice dictates creating dedicated, least-privilege service accounts for each distinct microservice.
2. Default Service Accounts: Created automatically when certain Google Cloud APIs are enabled:
   • Compute Engine Default SA: PROJECT_NUMBER-compute@developer.gserviceaccount.com
   • App Engine Default SA: PROJECT_ID@appspot.gserviceaccount.com
   • Critical Security Risk: Historically, default service accounts are automatically granted the primitive Editor role (roles/editor), granting excessive read/write permissions across the entire project. In production environments, default service accounts should have their Editor role revoked or be disabled entirely in favor of dedicated user-managed service accounts.
3. Google-Managed Service Agents: Created and maintained by Google to execute tasks on your behalf (e.g., service-PROJECT_NUMBER@cloudrun-service-accounts.iam.gserviceaccount.com). They are granted specialized internal roles.

Authentication Tokens: Access Tokens vs. ID Tokens

Workloads acquire credentials by querying the local Instance Metadata Server at http://metadata.google.internal/computeMetadata/v1/ using the mandatory HTTP header Metadata-Flavor: Google.

## Fetching an OAuth 2.0 Access Token (for calling Google Cloud APIs)
curl -s -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

## Fetching an OpenID Connect (OIDC) ID Token (for authenticating to Cloud Run/Cloud Functions)
curl -s -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://order-service-xyz.run.app"

The Anti-Pattern of Exported Private Keys

Downloading service account JSON private keys (sa-key.json) violates cloud security best practices:

• User-managed keys do not expire by default unless an applicable organization policy sets expiry; avoid distributing them.
• Keys are frequently leaked into source control, container layers, or logging sinks.
• Static key rotation requires additional operational controls; keyless identities reduce credential distribution and leakage risk.
• Resolution: Workloads running on Google Cloud must always leverage native metadata identity tokens or Workload Identity.

---

GKE Workload Identity

GKE Workload Identity is the recommended best practice for granting Kubernetes workloads secure access to Google Cloud services. It can grant resource IAM roles directly to a Kubernetes Service Account (KSA) principal. The following procedure illustrates the alternative IAM service-account impersonation model; it is not the only supported model.

+--------------------------------------------------------------------------+
| GKE Workload Identity Authentication Flow                                |
+--------------------------------------------------------------------------+
| GKE Pod (spec.serviceAccountName: order-ksa)                             |
|   |                                                                      |
|   | 1. Application invokes Google Cloud Client Library                   |
|   v                                                                      |
| GKE Pod Metadata Server (Intercepts metadata.google.internal)           |
|   |                                                                      |
|   | 2. Validates KSA identity: prod/order-ksa                            |
|   v                                                                      |
| Google Cloud IAM                                                         |
|   |                                                                      |
|   | 3. Checks Workload Identity Binding:                                 |
|   |    serviceAccount:PROJECT_ID.svc.id.goog[prod/order-ksa]             |
|   |    has roles/iam.workloadIdentityUser on order-gsa                       |
|   v                                                                      |
| 4. Returns short-lived OAuth 2.0 Access Token for order-gsa to Pod      |
+--------------------------------------------------------------------------+

Step-by-Step Implementation Procedure

Step 1: Enable Workload Identity on the GKE Cluster and Node Pools

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

For an existing Standard node pool, also configure --workload-metadata=GKE_METADATA on the node pool. Autopilot enables federation by default. A workload-pool setting alone does not retrofit every existing Standard node pool.

Step 2: Create the Google Service Account (GSA) and Grant IAM Roles

## Create GSA
gcloud iam service-accounts create order-gsa --project=my-project-id

## Grant Cloud Storage permissions to GSA
gcloud projects add-iam-policy-binding my-project-id \
    --member="serviceAccount:order-gsa@my-project-id.iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"

Step 3: Create the Kubernetes Service Account (KSA)

kubectl create namespace prod
kubectl create serviceaccount order-ksa --namespace prod

Step 4: Bind KSA to GSA via IAM

Grant the KSA permission to impersonate the GSA using the roles/iam.workloadIdentityUser role:

gcloud iam service-accounts add-iam-policy-binding \
    order-gsa@my-project-id.iam.gserviceaccount.com \
    --role="roles/iam.workloadIdentityUser" \
    --member="serviceAccount:my-project-id.svc.id.goog[prod/order-ksa]"

Step 5: Annotate the KSA

Annotate the KSA with the email address of the target GSA:

kubectl annotate serviceaccount order-ksa \
    --namespace prod \
    iam.gke.io/gcp-service-account=order-gsa@my-project-id.iam.gserviceaccount.com

Step 6: Deploy Pod Referencing the KSA

In the Kubernetes Pod specification, assign serviceAccountName: order-ksa. The application's Google Cloud client libraries automatically acquire tokens from the Pod Metadata Server without requiring credential files or environment variables.

---

Cloud Run Service Identity

On Cloud Run, managing service identity requires no cluster setup. Developers attach a dedicated user-managed service account directly during deployment:

gcloud run deploy payment-service \
    --image=us-central1-docker.pkg.dev/my-project/apps/payment:v1 \
    --service-account=payment-sa@my-project.iam.gserviceaccount.com \
    --region=us-central1

Service-to-Service Private Ingress Pattern

When Cloud Run Service A calls a private Cloud Run Service B:

1. Require IAM authentication on Service B and separately choose an ingress setting. Internal ingress is a network rule, not an identity check; calls from another Cloud Run service need a supported VPC/internal routing path when internal ingress is selected.
2. Service A fetches a signed OIDC ID Token from the metadata server with audience=https://service-b-url.run.app.
3. Service A adds the token to the request header: Authorization: Bearer <ID_TOKEN>.
4. Cloud Run frontends validate the token's cryptographic signature and verify that Service A's service account holds the Cloud Run Invoker role (roles/run.invoker) on Service B.