Eliminate static service account JSON keys using Workload Identity Federation. Secure your CI/CD pipelines with keyless authentication on GCP, AWS, and Azure.
Static service account keys are one of the biggest security risks in cloud environments. They get committed to repositories, leaked in logs, or stolen in supply chain attacks. The modern and secure way is to go completely keyless using Workload Identity Federation.
This approach allows your CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins, etc.) to authenticate to Google Cloud, AWS, or Azure without ever storing long-lived credentials.
In one large project I worked on, we had dozens of service account JSON files scattered across repositories. Even with strict secret scanning, the risk felt constant. Rotating keys was painful and error-prone. After a security audit highlighted this weakness, we decided to eliminate all static keys from our CI/CD pipelines.
How Workload Identity Federation Works
Instead of using a service account key, you configure a trust relationship between your CI/CD provider and the cloud provider. For Google Cloud, this is done through Workload Identity Federation using OIDC.The pipeline gets a short-lived ID token from GitHub (or your CI provider). This token is exchanged for a Google Cloud access token through a configured Workload Identity Pool and Provider. No JSON key is ever downloaded or stored.
Here’s the core idea in practice: In GitHub Actions, you use google-github-actions/auth which handles the token exchange automatically. You define the workload identity provider and the service account that the pipeline is allowed to impersonate.
The biggest advantage is that you can apply fine-grained IAM roles to the impersonated service account and set attribute conditions (e.g., only allow the main branch or specific repositories).
Production-Ready GitHub Actions Configuration
To implement this keyless approach, your GitHub Actions workflow file must explicitly request OIDC token permissions (id-token: write). Below is a clean, production-ready pipeline example using the official Google authentication action:
name: Secure Cloud Deployment
on:
push:
branches: [ main ]
# Crucial: Permissions required to request the OIDC JWT token
permissions:
id-token: write
contents: read
jobs:
deploy_to_gcp:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Authenticate via Workload Identity Federation
uses: google-github-actions/auth@v2
with:
project_id: 'your-gcp-project-id'
# Replace with your actual WIF provider path
workload_identity_provider: 'projects/123456789/locations/global/workloadIdentityPools/my-cicd-pool/providers/github-provider'
service_account: 'cicd-deployer@your-gcp-project-id.iam.gserviceaccount.com'
- name: Verify Cloud Connection
run: |
gcloud secrets versions access latest --secret="production-api-keys"
Implementation Challenges We Faced
The hardest part was migrating existing pipelines without breaking them. We started with non-critical workloads, then gradually moved everything.
The most common trap during migration is a mismatch in the attribute.repository mapping. If Google Cloud expects assertion.repository to restrict access strictly to your-username/your-repo, but your pipeline passes a different metadata structure, Google will reject the token with a cryptic 403 Forbidden or unauthenticated error, completely blocking the handshake.
Security and Operational Impact
After the migration, we no longer had any static service account keys in our repositories or CI secrets. Key rotation became unnecessary because there were no long-lived keys. Audit logs became cleaner because every action is tied to a specific workload identity. Pipeline runs also became slightly faster since there was no need to download and decrypt key files.
Final Thoughts
Moving to keyless authentication using Workload Identity Federation is one of the highest-ROI security improvements you can make in cloud-native environments. It removes a major attack vector, simplifies secret management, and aligns with modern zero-trust principles. If you are still using static JSON keys in your CI/CD pipelines in 2026, this is the right time to start the migration. The initial effort pays off quickly in reduced risk and operational simplicity. For more details on configuration, check the official Google Cloud Workload Identity Federation documentation and the GitHub Actions Google Auth action.