Why Workload Identity Federation Makes More Sense for Your CI/CD Pipelines

When working with CI/CD pipelines, especially at scale, managing secrets securely becomes a top priority. A common practice in many setups is to store and use Google Cloud Platform (GCP) service account keys in GitLab pipelines. While this approach might work for small, isolated environments, it introduces significant risks as your infrastructure grows and scales. Let’s break down the problems with this approach and explain why switching to Workload Identity Federation (WIF) using OIDC tokens is a better, more secure solution.

Risks of Using Service Account Keys in Pipelines

Service account keys have long been the default method for authenticating to cloud services - whether it’s Google Cloud, AWS, or Azure. But in the context of CI/CD pipelines, especially those running in public or multi-tenant environments, these keys become a major liability. The risks aren’t theoretical - they show up often and are hard to contain once something slips. Here's why this approach is problematic:

Key Leakage

Service account keys are critical credentials, and storing them in GitLab pipelines, whether directly in the .gitlab-ci.yml file, as environment variables, or in some form of secure storage, exposes the system to the risk of accidental leakage. These keys are often exposed during pipeline execution or in logs, which could be accessed by unauthorized users or compromised systems.

Let’s say a developer accidentally commits a .gitlab-ci.yml file containing hardcoded service account keys. If that repository is public, or if the file is checked into the wrong branch, those keys become immediately exposed to anyone with access to the repository. In many cases, pipeline logs or error messages may also contain the credentials being used, making it easier for attackers to access sensitive GCP resources if the keys are mismanaged.

Key Rotation Gaps 

Service account keys need to be regularly rotated to adhere to security best practices. However, this process is often cumbersome. Managing keys manually across multiple GitLab pipeline configurations makes it easy for updates to be missed or outdated keys to continue being used.

In large teams, it’s common for service account keys to be rotated periodically, but the old keys might remain in use because they were not updated in the repository or pipeline configurations. This leads to authentication failures and exposes gaps in the security posture, requiring manual intervention whenever an issue arises.

Hardcoded Secrets

Hardcoding service account keys in any part of the pipeline, whether in configuration files, environment variables, or in plain text in code, is a major security risk. Even if a secrets manager is used to store these keys, they can still be exposed if not managed properly during pipeline execution.

For example, a developer might accidentally log an error message containing the service account key, which could be exposed in plain text in the logs. This results in an easily exploitable vulnerability - hardcoding or mismanaging service account keys creates a ticking time bomb. If the keys are ever leaked, it could lead to a catastrophic security breach of GCP resources.

Why OIDC Tokens and Workload Identity Federation (WIF) Solve These Problems

The good news is that GCP’s Workload Identity Federation (WIF) and OIDC tokens offer a secure, keyless authentication model that can be easily integrated into GitLab CI/CD pipelines. This setup addresses the issues outlined above and provides a more scalable, secure approach to authentication. Here's how this setup solves the problems:

GitLab as the OIDC Identity Provider

GitLab can serve as an OpenID Connect (OIDC) identity provider, enabling it to authenticate users or services to GCP without requiring service account keys. When configured properly, GitLab generates an OIDC token for the service account being used in the pipeline. These tokens are short-lived and valid only for the duration of the pipeline run, reducing the risk of long-term exposure.

By using OIDC tokens, GitLab ensures that tokens can’t be misused in the long run because they are short-lived, scoped, and issued per job run - unlike static keys, they automatically expire and cannot be reused across sessions, making the authentication process significantly more secure.

GCP Workload Identity Federation (Identity Pools + Providers)

Instead of relying on long-lived service account keys, GCP Workload Identity Federation allows GitLab to authenticate directly using the OIDC token. The core pieces of this setup are:

• Identity Pools: These are collections of external identities (like those from GitLab) that GCP can trust. The identity pool allows GCP to accept tokens from GitLab and forms the first layer of authentication.
• Providers: The provider asserts the identity, which in this case is GitLab. This configuration ensures that only users or services authenticated by GitLab can interact with GCP resources.

This setup eliminates the need for storing long-lived service account keys within GitLab. Instead, GitLab CI/CD can authenticate to GCP using a short-lived OIDC token that is trusted by GCP, significantly reducing the attack surface.

Binding External Identities to GCP Service Accounts with Scoped IAM Roles

With Workload Identity Federation, these federated identities (such as GitLab’s service account) can be bound to GCP service accounts using IAM roles. These roles can be scoped to provide fine-grained access control. For instance, the service account used by the pipeline may only have permissions to read from GCS or deploy to a specific GKE cluster, rather than having full access to the entire GCP project.

This principle of least privilege is easier to enforce with federated identities. Instead of providing broad, unwarranted access via service account keys, IAM roles can be defined to specify exactly what each identity can do within the cloud environment. This makes the setup more secure and scalable as it grows.

A More Secure, Keyless Authentication Flow

By using OIDC tokens and GCP Workload Identity Federation, GitLab pipelines can authenticate to GCP without relying on service account keys. Here’s how the keyless authentication flow works:

1. GitLab CI/CD authenticates to GCP using an OIDC token-no service account keys are involved.
2. GCP uses Workload Identity Federation to validate the token from GitLab.
3. Access to resources is controlled via IAM roles that are scoped according to the principle of least privilege.

The diagram below shows how GitLab CI/CD integrates with GCP using OIDC tokens and Workload Identity Federation. It highlights the flow of authentication, from token generation to validation and access via scoped IAM roles:

This flow is cleaner, more secure, and easier to manage, as there’s no need to store, rotate, or worry about exposing service account keys. Instead, the federated identity setup leverages short-lived OIDC tokens to authenticate users or services, reducing the attack surface and simplifying the management of authentication credentials.

When to Use Workload Identity Federation - and When Not To

Workload Identity Federation (WIF) can be a powerful tool for securing CI/CD workflows, but it’s not always the best solution. Understanding when to use federated identity and when to rely on traditional methods like service accounts or secret managers is crucial for making the right security and architectural decisions. Below, we’ll explore specific use cases where WIF excels and other scenarios where using service accounts or secret managers might still be the better choice.

When Workload Identity Federation Makes Sense

1. Short-Lived Jobs Workload Identity Federation is an excellent fit for scenarios where jobs are short-lived. CI/CD pipelines often include steps like building, testing, or deploying code that don't need long-term access to cloud resources. These jobs run for a limited time, and the access required to perform tasks (e.g., deploying a Kubernetes service or pushing a Docker image) can be granted temporarily.
   
   WIF is especially effective here, as it generates short-lived OIDC tokens that are valid only for the duration of the job. Once the job completes, the token expires and cannot be used again. This minimizes security risks related to long-lived credentials.
   
   For example, consider a pipeline that runs integration tests in Google Cloud. The job doesn’t need continuous access to resources; it only needs authentication to pull images from a container registry or deploy to a test GKE cluster. By using WIF, the pipeline can authenticate via GitLab's OIDC token, and the token will automatically expire once the job is finished. This approach reduces the potential for misuse or mismanagement of long-lived credentials.
   
   
2. Stateless CI Pipelines Stateless CI pipelines, where each job is independent of the others and doesn’t carry state between runs, are also a great fit for Workload Identity Federation. In these types of pipelines, there’s no need to store or manage persistent credentials. Each job is designed to execute in isolation, meaning any credentials needed for authentication can be provided on-the-fly, without maintaining long-term access to resources.
   
   For example, in a pipeline that runs automated unit tests in isolated environments (like containers or VMs), no credentials need to persist from one job to the next. By using WIF, GitLab can generate OIDC tokens at the start of each job, ensuring that only temporary access is granted during the execution of that specific pipeline run. This eliminates the need for storing sensitive credentials or using secrets managers.
   
   
3. No Access to Secret Stores When systems do not have access to a centralized secret store, Workload Identity Federation offers a practical solution. Secret managers like Google Secret Manager or HashiCorp Vault are great tools for storing service account keys securely, but not every environment has access to such services. In these cases, WIF allows CI/CD systems to authenticate directly with cloud platforms without the need for hardcoding or storing service account keys.
   
   For instance, a small-scale cloud-native application might not have access to a centralized secret store or may operate in an isolated environment. In this case, setting up federated identity allows GitLab to authenticate directly with Google Cloud without needing to store or manage long-lived credentials in the pipeline itself. Instead, it relies on OIDC tokens generated by GitLab for the duration of the pipeline job.
   
   

When Workload Identity Federation May Not Be Ideal

While WIF is an excellent fit for many modern CI/CD scenarios, it’s not a one-size-fits-all solution. There are situations where traditional service accounts or secret management systems still make more sense. Let’s look at those cases:

1. Legacy Systems and Long-Running Services For legacy systems that require persistent, long-term access to cloud resources, WIF may not be the best fit. These systems may rely on long-running services that need continuous access to GCP resources, such as databases, VMs, or persistent storage.
   
   For example, a legacy monolithic application that runs on Google Compute Engine (GCE) might need ongoing access to GCP resources even when there are no active pipeline runs. In such cases, using traditional service accounts with long-lived keys is often more practical. Workload Identity Federation is best suited for short-lived, stateless jobs, not systems requiring permanent access.
   
   
2. Local Development Environments While WIF is a fantastic solution for CI/CD environments, it’s less practical for local development environments. Developers working on their machines might require different authentication mechanisms, especially when they need access to cloud resources for local testing, debugging, or development.
   
   For example, a developer working locally might find it more convenient to use a service account key or set up local access via a secrets manager rather than going through the process of setting up Workload Identity Federation on their machine. Additionally, WIF’s reliance on GitLab as an OIDC provider might not be a fit for developers who need more flexibility in their authentication setup.
   
   

Workload Identity Federation offers a modern, secure, and scalable solution for authenticating CI/CD pipelines with cloud providers like Google Cloud. It’s particularly suited for short-lived, stateless jobs in CI pipelines where there is no need for persistent credentials. However, for legacy systems, long-running services, and local development environments, traditional service accounts or secret managers may still provide a more appropriate solution. Understanding these trade-offs is key to making the right choice based on your infrastructure and security needs.

Authenticating to GCP from GitLab Using Workload Identity Federation

So far, the case has been made for why Workload Identity Federation (WIF) is a better fit for CI/CD authentication than service account keys. Now it’s time to wire it all up.

The goal is simple: enable GitLab CI/CD pipelines to authenticate directly with Google Cloud using OIDC tokens, no keys or secrets involved.

This walkthrough sets up everything end to end:

• Configuring Google Cloud to trust GitLab tokens
• Binding those tokens to scoped IAM roles via a GCP service account
• Setting up a GitLab pipeline that uses federated credentials to run gcloud and Terraform commands

Step 1: Enable Required GCP APIs

Before anything else, ensure that the core services used for federation are enabled on your project:

You’ll see an output confirming that the operation has completed successfully:

‍

Step 2: Create a Workload Identity Pool

A workload identity pool is a logical boundary where Google Cloud can receive and trust identities from external sources.

Once created, GCP will output:

‍

Step 3: Create the OIDC Provider (GitLab)

Now configure GitLab as a valid OIDC provider inside the pool. This tells Google to accept OIDC tokens issued by GitLab and sets up claim mappings and constraints.

‍

Expected output:

‍

Step 4: Create a GCP Service Account for GitLab

This is the GCP identity that GitLab pipelines will impersonate.

Output:

‍

Step 5: Grant IAM Permissions to the Service Account

Now bind this service account to the roles needed by your pipeline - for example, access to GCS buckets:

‍

Output:

Deploying to GCP from GitLab Using Federated Credentials

Now that the identity federation between GitLab and Google Cloud is fully wired up, it’s time to put it to work by running a real deployment pipeline. The idea is simple: GitLab generates a short-lived OIDC token, GCP verifies it through Workload Identity Federation, and Terraform uses the resulting access token to provision infrastructure.

There’s no key file anywhere. No secrets. Just an ephemeral token generated on demand.

This setup uses a two-stage GitLab pipeline: one stage prepares the access token using GitLab’s built-in OIDC token and Google’s STS API; the second uses that access token to run Terraform against GCP. The only secret in the entire flow is the access token itself-and that’s short-lived and scoped.

Here’s the minimal Terraform setup used in the pipeline. This example creates a random-suffix Google Cloud Storage bucket:

‍

This code expects two environment variables to be passed in at runtime:

And

These are created during the first GitLab pipeline stage.

Here’s the actual .gitlab-ci.yml pipeline used to run this setup:

This pipeline does exactly what you’d expect: authenticates using GitLab’s OIDC token, exchanges it with GCP for an access token, and passes that token along to Terraform for deployment.

‍

The next stage runs Terraform. If everything is configured properly, Terraform will initialize, fetch the providers, plan the GCS bucket creation, and apply it in one go.

Here’s what a successful Terraform execution looks like in the job log:

This verifies that GitLab was able to authenticate to GCP, use the federated access token, and run Terraform using zero hardcoded credentials.

This was a complete keyless Terraform deployment. No static credentials were stored. No .json key file was checked in or passed around. GitLab generated a token, GCP verified it using Workload Identity Federation, and Terraform did its job using that federated token.

This is what modern CI/CD authentication looks like-short-lived, scoped, auditable, and fully automated.

Best Practices for Running Federated Identity at Scale in GitLab CI/CD

Once the GitLab-to-GCP federation is up and running, the next challenge is scaling it safely. What works fine for a single pipeline or project can quickly become fragile when dozens of environments, roles, and tokens come into play. These practices are based on what actually holds up under pressure-across multiple teams, regions, and environments.

Use Least Privilege IAM Roles and Scoped Permissions

Don’t treat the federated service account as a root user. Bind only the IAM roles that are absolutely necessary for the job the pipeline is doing. If a pipeline needs to deploy Cloud Run services, give it roles/run.admin and nothing more. If it only pulls artifacts, roles/artifactregistry.reader is enough.

Every federated identity should be paired with a minimal service account that does exactly one thing. This ensures that even if a token is leaked or misused, the blast radius stays small.

Isolate Workload Identity Pools Per Environment

Avoid putting all environments-dev, staging, prod-under the same identity pool. It becomes too easy to mix permissions, leak tokens across stages, or grant production access where it doesn’t belong.

A cleaner design is to create separate pools like gitlab-wip-dev, gitlab-wip-staging, and gitlab-wip-prod, each mapped to its own namespace or claim restriction. This makes cross-environment access impossible by default and ensures clean boundaries.

Monitor and Alert on Token Exchange Activity

Federated tokens are short-lived, but they’re still credentials. Make sure there’s visibility into when and how they’re used. Enable Cloud Audit Logs for the sts.googleapis.com service and set up alerts for unusual behavior-such as token exchanges outside pipeline hours or unexpected spikes.

If an attacker ever tries to exploit the setup by misusing GitLab’s OIDC integration, token exchange logs will be your first line of defense.

Avoid Overly Broad Token Claim Mappings

When mapping claims from GitLab to GCP identities, don’t just trust assertion.sub or allow all namespaces. Be explicit. For example, restrict access to only a specific GitLab group or project path using:

--attribute-condition="assertion.namespace_path.startsWith(\"your-group-name\")"

This ensures that only identities originating from the intended part of your GitLab organization can impersonate service accounts in GCP. Overly permissive claim mappings are how things spiral into snowflake configs that are hard to reason about later.

By sticking to these principles, the federated identity setup stays clean, traceable, and secure-even as the number of pipelines and environments grows. It’s not just about replacing keys-it’s about building a scalable foundation for modern CI/CD authentication.

Firefly Workspaces: Enhancing GitLab CI/CD Pipelines

Workload Identity Federation solves a big part of the CI/CD security part - eliminating static credentials. But authentication is just one part. To truly secure and govern infrastructure at scale, teams need visibility into what’s changing, enforce policies before anything hits production, and catch drift as it happens. That’s where Firefly comes in.

When GitLab pipelines are used to manage infrastructure, especially in fast-moving teams or multi-environment setups, it becomes hard to track what's being deployed and whether it meets compliance standards. This is where Firefly comes in. By integrating directly into GitLab CI/CD workflows, Firefly acts as a control plane that analyzes infrastructure changes - before they’re applied. It inspects Terraform plans in real-time, blocks non-compliant deployments, and enforces policies defined by the organization. This prevents security risks and misconfigurations from slipping through the pipeline, without slowing down developers.

For example, say a developer tries to spin up a storage bucket without encryption or opens up a firewall rule to the public internet. Firefly will block that plan from being applied—right inside the GitLab job - before anything reaches production. The rules are codified as Guardrails, and they’re evaluated as part of the CI workflow. No manual review required. No guesswork.

This enforcement layer isn’t limited to Terraform either. Firefly works across various cloud resources and IaC tools, watching for violations across infrastructure definitions.

But Firefly doesn’t stop at deployment. Once infrastructure is in production, Firefly continuously monitors it to detect drift - any changes made manually, outside GitLab. If someone tweaks a setting in the GCP console, Firefly flags it, compares it with the source of truth, and raises a violation. This helps maintain consistency and keeps the stack audit-ready.

Drift detection is important in federated CI/CD pipelines where permissions are tight and environments evolve fast. Without it, small changes can compound into security holes or misconfigurations that are hard to trace.

Another key value Firefly brings is cost visibility. As infrastructure scales, costs can spiral. Firefly analyzes cloud usage patterns and highlights inefficiencies - like underutilized resources, oversized machines, or forgotten test environments that are still running. These insights feed directly into the GitLab pipeline reports, giving teams a chance to fix issues before they eat up budget.

This kind of integration turns GitLab from a deployment engine into a fully governed delivery pipeline. Developers can deploy with confidence, knowing their code will only be applied if it’s compliant. Security teams don’t have to audit every plan manually. And ops teams get real-time feedback on configuration drift and spending.

In short, combining Firefly with Workload Identity Federation gives you authentication without keys, enforcement without bottlenecks, and visibility without compromise.

‍