In this case study, I’ll walk you through how I migrated a SaaS platform from static service account keys to a keyless authentication model with Google Cloud Workload Identity Federation (WIF) — improving security, reducing credential management overhead, and enabling secure hybrid workloads.
Many SaaS teams realize that Service Account (SA) keys are a liability, yet they remain in place because they “just work.” But in 2026, “it works” isn’t a security posture—it’s a countdown.
I recently partnered with a high-growth SaaS startup (a no-code application platform) to replace their long-lived static keys with Keyless Authentication via Workload Identity Federation (WIF). This wasn’t just a technical swap; it was a material upgrade to their “Golden Gate” infrastructure.
Workload Identity Federation (WIF) lets external applications authenticate to Google Cloud without long-lived service account keys. Instead of managing and rotating static key files, WIF exchanges tokens from an external identity provider (like AWS, Azure, GitHub Actions, or OIDC providers) for short-lived Google Cloud credentials, reducing risk and simplifying credential management.
Before the migration, the client’s authentication model was typical—and fragile.
Static Keys: JSON keys were scattered across GitHub Repository Secrets and developer laptops.
Broad Scoping: Single service accounts were reused across multiple repos and environments (Dev/Prod).
No Rotation: Ownership of key rotation was non-existent; some keys were over two years old.
Blast Radius: A single leaked key from a developer’s machine could provide permanent, unmonitored access to production data.
We evaluated traditional fixes, like automated key rotation or Vault-based distribution. However, Workload Identity Federation (WIF) won because it fundamentally changed the trust model:
Zero Stored Keys: No credentials to leak from GitHub or laptops.
Identity-Based Trust: Access is granted based on the identity of the workload (e.g., a specific GitHub Repo + Branch).
Ephemeral Access: Tokens are short-lived (default 1 hour) and issued on-demand by the Security Token Service (STS).
Instead of repo-level snowflakes, we implemented a centralized Workload Identity Pool in a dedicated security project. This allows the platform team to govern all external access from a single pane of glass.
We didn’t just trust “GitHub.” We used Common Expression Language (CEL) to map specific claims:
google.subject = assertion.sub
attribute.repository = assertion.repository
The Guardrail: We applied an attribute condition ensuring only the client’s specific GitHub Org and main branch could exchange tokens for production access.
We opted for Service Account Impersonation rather than direct federated access.
The Logic: The federated identity (GitHub) is granted the roles/iam.workloadIdentityUser role on a specific GCP Service Account.
The Benefit: This maintains a clean audit trail and allows us to use existing IAM roles without refactoring the entire permission structure.
All authentication flows through the Security Token Service (STS).
GitHub issues a signed OIDC token.
STS validates the signature and exchanges it for a federated token.
IAM exchanges that for a short-lived GCP Access Token.
| Feature | Before (SA Keys) | After (WIF/Keyless) |
| Credential Lifespan | Years (Manual) | 60 Minutes (Automatic) |
| Secret Storage | GitHub Secrets / Laptops | None |
| Onboarding | Manual Key Creation | Policy-based (Automatic) |
| Audit Detail | Service Account Name Only | SA Name + GitHub Repo + Branch |
Security: Eliminated 100% of static GCP credentials in CI/CD. For teams running GKE workloads, the next step after eliminating static keys is hardening the cluster itself — see GKE Hardening: How I Secure Kubernetes Clusters by Default. If you’re also managing secrets inside GKE pods, 4 Ways to Inject GCP Secrets into GKE covers the options in detail.
Velocity: Onboarding new services dropped from hours of manual “secret plumbing” to minutes of Terraform policy updates.
Compliance: The team passed their SOC2 Type II identity review with zero findings.
This transition isn’t just a “checkbox.” It requires a shift in how you treat identity.
IAM messages are opaque: Debugging a failed STS exchange requires looking at the Cloud Audit Logs for the ExchangeToken event—don’t rely on the CI/CD logs alone.
Visual Documentation: We found that developers didn’t “get it” until we provided a visual flow of the OIDC handshake.
Platform Capability: Treat WIF as a capability you offer developers, not just a security restriction.
Static keys are security debt. If your platform relies on GitHub Actions or GKE, you are one leak away from a major incident.
If your platform’s identity model needs a broader review — not just WIF but IAM structure, org policies, and access controls end-to-end — that’s exactly what I cover in a free GCP architecture consultation. The DevSecOps & Cloud Security service page covers how I approach this as an engagement.
JSON keys are long-lived “static secrets”—if they are leaked, they remain valid until manually revoked. I prefer WIF because it uses short-lived, identity-based tokens that expire automatically. This removes the management overhead of key rotation and drastically reduces your attack surface.
The migration is surprisingly straightforward. I focus on setting up a Workload Identity Pool and Provider, then updating your YAML to exchange a GitHub OIDC token for a GCP token. It eliminates the need to store secrets in GitHub, making your CI/CD pipeline “keyless” and enterprise-ready.
