Workload Identity Federation, or WIF, is a way to authenticate non-GCP systems, such as GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, and other third-party CI/CD tools, with Google Cloud services without using long-lived service account keys. Instead of relying on static credentials, WIF allows these external platforms to obtain short-lived tokens that Google Cloud verifies at runtime. If the token is valid, access is granted based on predefined GCP IAM roles.

Previously, authentication between third-party CI/CD platforms (such as GitHub Actions, GitLab CI/CD, and Bitbucket Pipelines) and GCP required storing service account keys. This approach had several drawbacks. Service account keys remain valid indefinitely unless explicitly revoked, requiring regular rotation through automated key management. If a single key is shared across multiple workflows or users, it becomes difficult to track which specific workflow or user accessed Google Cloud resources, increasing security risks.

WIF removes these challenges by eliminating service account keys entirely from the authentication process. Authentication happens dynamically, with GitHub Actions, GitLab CI/CD, and other external workloads exchanging identity tokens for temporary access. This makes sure that permissions are granted only when needed, reducing any kind of security risks and making access control more manageable for the team.

Workflow of WIF

Now, when a Google GitHub Actions workflow runs, it first requests an identity token from GitHub’s OpenID Connect (OIDC) provider. This token includes metadata such as the repository name, workflow details, and the trigger event. GitHub then signs the token to ensure its integrity before providing it to the workflow.

Once the workflow receives the signed token, it sends it to GCP IAM for authentication. Google Cloud does not validate the token directly. Instead, it forwards the request to a Workload Identity Pool, which acts as a bridge between external identity providers like GitHub and Google Cloud. The Workload Identity Pool evaluates the token against the configured trust conditions to determine if the request originates from an approved repository and workflow.

If the token meets all trust conditions, GCP IAM maps the external identity to a specific service account. This service account has predefined IAM roles that control the actions the workflow can perform. Rather than issuing permanent credentials, GCP generates short-lived credentials that are valid only for a limited time, making sure that access is granted only for the duration of the workflow execution.

With these temporary credentials, GitHub Actions can now interact with GCP services as permitted by the assigned IAM roles. Once the credentials expire, the workflow loses access, eliminating the risks associated with static service account keys. This process ensures a secure, scalable, and efficient way to integrate CI/CD pipelines with GCP while maintaining strict access controls and reducing credential management complexity.

Configuring Google Cloud for WIF

Now, let’s go through the process of configuring Google Cloud to authenticate external systems, such as Google GitHub Actions, using WIF. This configuration allows external platforms to securely access Google Cloud resources without using static credentials or service account keys. By the end of this section, you will have set up a Workload Identity Pool, added an identity provider, configured attribute mapping, linked a service account, and assigned appropriate roles. Let's walk through the configuration step by step.

1. Creating a Workload Identity Pool

To start, create a Workload Identity Pool in Google Cloud, which will act as a bridge for federating external identities. The pool serves as a central point where external identity tokens from services like GitHub are validated.

Navigate to the Workload Identity Pools section in the Google Cloud Console and click on Create Pool. Provide a name for your pool, such as github-wif, and then proceed to create it. Once the pool is created, it will serve as the container for the external identities that will authenticate against Google Cloud.

2. Setting Up an Identity Provider

With the pool created, the next step is to configure your external identity provider, in this case, GitHub. GitHub will issue identity tokens to authenticate users or workflows, which will then be validated by Google Cloud.

Go to the Workload Identity Pools section and click on Add Provider. In the Provider Name field, enter github (or another suitable name for the provider). For the Issuer URL, enter GitHub's OpenID Connect (OIDC) provider URL: https://token.actions.githubusercontent.com. This is the URL that Google Cloud will use to verify the identity tokens issued by GitHub.

Once the provider is configured, enable it to allow external identities to authenticate using the provider. If your identity provider isn't publicly accessible, you can upload a JWK file to Google Cloud to validate the tokens.

3. Attribute Mapping Configuration

Before linking the identity provider to a service account, it’s important to configure Attribute Mapping. This step ensures that the external identity attributes are correctly mapped to GCP IAM attributes. This allows you to define which attributes from the external identity provider, such as GitHub, should be used to determine access to resources.

In the Attribute Mapping section, you can map the identity attributes provided by GitHub (such as repository information) to Google Cloud attributes. For example, you can map GitHub’s repository name (assertion.repository) to a Google Cloud attribute like attribute.repository. This mapping ensures that only requests coming from specific repositories or actions are granted access.

For instance, you might want to map the assertion.repository attribute to a specific repository in GitHub, using the following condition:

assertion.repository=='Cipher-08/gcp-wif-demo'

This condition ensures that only requests originating from the gcp-wif-demo repository in GitHub will be allowed to authenticate and interact with Google Cloud resources.

4. Linking the Identity Provider to a Service Account

Once the attribute mapping is configured, the next step is to link the identity provider to a service account. The service account will be granted permission to interact with Google Cloud resources based on the attributes mapped in the previous step.

Navigate to the Service Accounts section under IAM & Admin in the console. Click Create Service Account and give it a descriptive name, such as github-actions-sa. Optionally, add a description and click Create.

After creating the service account, link it to the identity provider by adding a binding IAM policy. This step is important because it grants the service account the ability to assume roles based on the identities validated by the provider. You can run the following gcloud command to link the service account to the identity provider and the repository in GitHub:

gcloud iam service-accounts add-iam-policy-binding "github-actions-sa@${PROJECT_ID}.iam.gserviceaccount.com" \ --project="${PROJECT_ID}" \ --role="roles/iam.workloadIdentityUser" \ --member="principalSet://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/my-pool/attribute.repository/my-org/my-repo"

This command binds the service account github-actions-sa to the identity provider and restricts the authentication to a specific repository in GitHub 

Configuring GitHub Actions for Federation

Once WIF is configured, the next step is to set up Google GitHub Actions workflows to authenticate with Google Cloud using the federated identity.

1. Modifying the GitHub Actions Workflow

Next, you need to update your GitHub Actions workflow to use the federated identity token for authentication. Below is an example of a GitHub Actions YAML configuration that authenticates using the identity provider you configured in Google Cloud:

name: 'Terraform' on: push: branches: [ "main" ] pull_request: permissions: contents: read id-token: 'write' jobs: terraform: name: 'Terraform' runs-on: ubuntu-latest defaults: run: shell: bash steps: # Checkout the repository to the GitHub Actions runner - name: Checkout uses: actions/checkout@v3 - id: auth uses: google-github-actions/auth@v2.0.0 with: workload_identity_provider: 'projects/583679955132/locations/global/workloadIdentityPools/github-wif/providers/github' service_account: 'github-wif@content-gen-418510.iam.gserviceaccount.com' - name: Setup Terraform uses: hashicorp/setup-terraform@v3 - name: Terraform Init run: terraform init # Generates an execution plan for Terraform - name: Terraform Plan run: terraform plan -input=false - name: Terraform Apply run: terraform apply -auto-approve -input=false

In this example, the google-github-actions/auth action is used to authenticate the GitHub Actions workflow with Google Cloud using the federated identity provider. It will authenticate using the service account github-wif@content-gen-418510.iam.gserviceaccount.com.

Testing the Integration

With the configuration complete, it’s time to test the integration and verify that Google GitHub Actions successfully authenticates with Google Cloud.

1. Triggering GitHub Actions

To test the setup, trigger a GitHub Actions workflow by pushing changes to the main branch or opening a pull request. The workflow will authenticate with Google Cloud using the federated identity token issued by GitHub.

2. Validating Access to Resources

Once the workflow runs, check the GitHub Actions logs to verify whether it successfully authenticated with Google Cloud and gained access to the resources. 

From the logs in the screenshot, we can see the key step where WIF is being used:

In this log:

  • workload_identity_provider → This connects GitHub Actions with Google Cloud’s Workload Identity Pool for authentication.
  • service_account →Instead of using long-lived service account keys, GitHub Actions is obtaining short-lived credentials using WIF.
  • create_credentials_file: true → This temporary file is used to authenticate requests securely without needing static keys.
  • export_environment_variables: true → This allows Terraform or other tools to use them during infrastructure deployment.

By following these steps, you can securely integrate GitHub Actions with Google Cloud using WIF, eliminating the need for static service account keys.

Best Practices

Now that we’ve set up WIF (WIF) with GitHub Actions, it’s important to follow some best practices to ensure security, efficiency, and scalability. Implementing these practices will help you maintain control over access and reduce potential risks. Let’s dive into the key practices you should follow.

Least-Privilege Access

One of the most important practices when configuring WIF is least-privilege access. This principle ensures that federated identities are granted only the minimum permissions necessary to perform their tasks. By limiting access, you reduce the risk of exposing critical resources to unauthorized entities.

For example, if a CI/CD pipeline only needs to read from Cloud Storage, assign it the roles/storage.objectViewer role instead of more permissive roles like roles/editor. Always ensure that federated identities only have the permissions required for their specific function.

Role-based Access Reviews

It's also important to periodically review the roles assigned to federated identities. As your cloud environment evolves, access needs may change. Regular reviews help to prevent privilege creep, where identities accumulate unnecessary permissions over time.

Conducting routine access reviews ensures that roles assigned to federated identities are still aligned with their current needs. If a federated identity no longer requires certain permissions, they should be revoked immediately to reduce potential risks.

Monitoring and Auditing Access

Logging and monitoring are important to track the usage of federated identities. Use Cloud Audit Logs and Cloud Monitoring to keep track of actions performed by federated identities and set up alerts for any unusual or unauthorized activity.

Cloud Audit Logs capture details of which federated identities are accessing specific resources, while Cloud Monitoring allows you to set up alerts for suspicious behaviors, such as failed authentication attempts. Monitoring and auditing will help you detect and respond to any security issues promptly.

By following these best practices, you ensure that your WIF setup remains secure, efficient, and well-managed. These practices help reduce risks and ensure that federated identities only have the access they need to perform their tasks.

Firefly Workspaces: Enhancing Your CI/CD Pipelines

Now, when working with third-party CI/CD services like GitHub Actions, one common approach is to generate and store access keys for authentication. These services are considered external to Google Cloud, as they operate outside the GCP ecosystem. In contrast, internal services refer to applications and workloads running within GCP, such as Compute Engine instances or Cloud Functions, which can natively use IAM roles without requiring additional authentication mechanisms.

While storing access keys for external services may seem simple, it introduces several risks, including security vulnerabilities and the need for constant key rotation. A more secure approach is to implement WIF, which eliminates the need for static credentials by providing temporary authentication tokens that are verified at runtime. However, simply adopting WIF doesn’t completely address all security challenges within your CI/CD pipeline.

To strengthen security, maintain compliance, and optimise your CI/CD pipeline, you need additional controls beyond just authentication. This is where Firefly helps. By integrating Firefly into your CI/CD workflows, you can enforce security policies, block non-compliant actions before deployment, and gain better visibility into infrastructure changes. Instead of just reacting to issues, Firefly ensures that every action meets your organisation’s security and operational standards from the start.

Firefly works alongside your WIF configuration to provide an additional layer of security through automated checks known as Guardrails. 

These Guardrails help enforce custom policies within the pipeline, making sure that any actions which don’t meet compliance standards or security protocols of an organization are blocked before they can be executed. For example, Firefly makes sure that all resources deployed are compliant with your security practices and organizational policies, blocking anything that violates predefined rules, such as deploying unencrypted resources or exposing critical services to the public internet.

Beyond just enforcing compliance during deployment, Firefly provides continuous monitoring after infrastructure is deployed. It tracks potential infrastructure drift, making sure that your deployed resources remain in line with the desired configuration. This helps prevent unexpected changes that could introduce vulnerabilities or misconfigurations into your environment. Additionally, Firefly detects policy violations and alerts you to any issues that arise after deployment, ensuring that security policies and operational guidelines are adhered to at all times.

Firefly also optimizes your infrastructure by identifying cost inefficiencies. Over time, cloud environments can accumulate underutilized or over-provisioned resources, leading to unnecessary costs. Firefly helps track these inefficiencies and provides insights into how resources can be better optimized, allowing you to manage costs more effectively while maintaining the performance of your infrastructure.

Incorporating Firefly into your CI/CD pipeline elevates the security, compliance, and efficiency of your infrastructure management. By enforcing rules, monitoring for drift, tracking policy violations, and identifying cost inefficiencies, Firefly ensures that your pipeline is not only secure but also optimized and cost-effective. This integration transforms your pipeline into a more robust, well-governed process, enabling you to deploy and manage cloud resources with confidence.

FAQ 

How do I set up WIF with GitHub Actions?‍

To set up WIF, create a Workload Identity Pool in Google Cloud, configure GitHub as an OpenID Connect (OIDC) provider, map attributes (like the repository name), and link the provider to a service account in Google Cloud. Finally, update your GitHub Actions workflow to use the federated token.

What are the security benefits of WIF?‍

WIF eliminates static service account keys, reducing security risks. It uses short-lived tokens that expire after each session, minimizing unauthorized access. This improves access control and reduces the risk of key compromise.