AK°

Engineering note · 02 Cloud & security

Removing long-lived credentials
from a Google Cloud pipeline.

How Workload Identity Federation and Application Default Credentials replaced a static service-account key in a CI/CD pipeline—and why the extra IAM setup was worth it.

Topic

Cloud & security · Workload Identity Federation, ADC, IAM

Grounded in

The India Hidden Gems platform build

The problem 01

A service-account key is a permanent secret waiting to leak.

A long-lived JSON service-account key is a common way to give a CI/CD pipeline access to Google Cloud. It is also a standing liability: once generated, it remains valid until someone manually rotates or revokes it, and it sits in a CI configuration looking and behaving exactly like any other secret.

For the India Hidden Gems pipeline, that was a risk not worth carrying into production, even for a small, early-stage platform. The goal was to authenticate the pipeline using identity rather than a stored secret, so credentials expire automatically and there is nothing long-lived to leak, rotate, or forget about.

How it works 02

GitHub Actions→OIDC token→Workload identity pool→Short-lived GCP credentials

Exchange identity for a credential, not a key.

Workload Identity Federation lets an external identity provider—GitHub Actions, here—present a signed OIDC token to Google Cloud. Google exchanges that token for short-lived, scoped credentials, without a Google-issued key ever being stored inside the CI system.

Locally and in other Google-managed contexts, Application Default Credentials provide the same identity-based pattern: the environment already has a way to authenticate, so the application asks for credentials rather than embedding them.

GitHub ActionsOIDCWorkload Identity PoolGoogle Cloud IAMADCTerraform

Key decisions 03

WIF for CI/CD

Configure a workload identity pool and provider scoped to the pipeline instead of issuing a service-account key.

Trade-off: more upfront IAM and pool configuration than pasting in a key.
ADC everywhere else

Use Application Default Credentials wherever the runtime already carried a trusted identity, keeping key management out of application code.

Trade-off: each environment has to be configured correctly rather than "just working" with a dropped-in key.
Least-privilege IAM

Scope the federated identity to only the roles the pipeline actually needed—image push and deployment—rather than a broad service-account role.

Trade-off: permissions had to be revisited as the pipeline's responsibilities grew.
Terraform-managed identity

Define the workload identity pool, provider, and IAM bindings as code so the setup was reproducible and auditable.

Trade-off: added Terraform configuration before the first deployment could run.

What changed 04

Nothing long-lived left to leak.

  • No service-account JSON key stored in CI/CD
  • Credentials issued per pipeline run, short-lived by default
  • IAM bindings scoped to the specific roles the pipeline needed
  • Identity configuration defined and versioned in Terraform
  • The same identity-based pattern reused for local and server authentication via ADC

Lessons 05

A key that doesn't exist can't leak.

Short-lived credentials turn "rotate this secret" into "nothing to rotate."

IAM setup is real work up front—budget for it.

Identity-based access scales down to small projects, not just large ones.

Reproducible IAM config in Terraform beats a one-time console change.

Working with credentials like this? 06

Let's remove the
standing risk.

If a pipeline, service, or team is still passing around long-lived keys, I'd be glad to talk through what identity-based access would take.

Start a conversation ↗