Skip to main content

OIDC for GCP

Abstract

Generate OIDC tokens during your Bitrise build to exchange them for scoped access tokens with Google Cloud Platform

Generate OIDC tokens during your Bitrise build to exchange them for scoped access tokens with Google Cloud Platform (GCP).

To use OIDC tokens for GCP, you'll need to:

  • Create a workload identity pool.

  • Connect a Google service account to the identity pool.

On Bitrise, you can get the tokens by using either the Get OICD identity token Step or the Authenticate with GCP Step.

Creating a workload identity pool

Create a workload identity pool in GCP to enable Workload Identity Federation.

Workload Identity Federation

Read more about how authentication with Workload Identity Federation works on GCP in the official Google documentation.

  1. In the Google Cloud console, go to IAM & Admin then Workload Identity Federation.

  2. In the Create an identity pool section, enter a value for the following fields:

    • Name: The name for the pool. The name is used as the pool ID and you can't change the pool ID later.

    • Description: The purpose of the pool.

  3. Under Add a provider to pool, add Bitrise as a provider:

    • In the Select a provider field, select OpenID Connect (OIDC).

    • Provider name: Enter a name. For simplicity, we recommend using Bitrise.

    • Issuer URL: https://token.builds.bitrise.io.

    • Audience: Select Allowed audience. When using the token, GCP will check if the allowed audience matches the audience encoded in the aud claim. On Bitrise, you can set the audience in our Steps providing OIDC services: Fetching and exchanging tokens with GCP.

  4. Click Continue.

  5. Under Configure provider attributes, configure the required attribute mapping values:

    • The google.subject key is a unique identifier for the user. You can use assertion.sub to identify the build that requests the token.

    • Use the attribute.NAME format to add up to 50 custom attributes, each with a value in the assertion.VALUE format. You can find the list of available attributes in the Bitrise token here: Information in the OIDC token.

    Explicit mapping required

    You must map all the attributes you want to use. Google only lets you use the attributes which are explicitly mapped. Read more about attribute mappings in Google's documentation.

  6. Optionally, add attribute conditions. You will also be able to filter identity tokens based on attributes directly at the pool level when creating the service account.

Your final configuration might look something like this:

2025-11-18-oidc-gcp.png

Connecting a Google service account to the workload identity pool

To start using OIDC authentication for GCP services, you need to connect a workload identity pool to a Google service account. This involves:

  • Creating a service account.

  • Granting access to the identity pool using a service account impersonation.

Create a service account

  1. In Google Cloud console, go to IAM & Admin and then Service accounts.

  2. Click Create service account.

  3. Add a display name, a unique service account ID, and a description.

  4. Click Create and continue.

  5. Under Permissions, add all roles that you need.

    IAM conditions

    Optionally, you can add IAM conditions based on the previously mapped attribute values by clicking Add IAM condition.

  6. Click Done.

Granting access to the workload identity pool

  1. In Google Cloud console, go to IAM & Admin and then Workload Identity Federation.

  2. Select your identity pool.

  3. Click Grant access.

  4. Select the Grant access using service account impersonation option.

  5. Select the service account you've created.

  6. Select the principals: identities that can access the service account.

    The available options are limited to the keys from the provider attribute mapping of the identity pool. For example, if you use the attribute mapping google.subject=assertion.sub, set Attribute name to subject and Attribute value to sub. You can see the available values in the Bitrise token here:

  7. Click Save.

  8. In the dialog, select the provider you created for Bitrise OIDC tokens.

  9. Add the OIDC ID token path: https://token.builds.bitrise.io and set the format to text.

  10. Click Download config and save the file somewhere you can access it.

Fetching and exchanging tokens with GCP

After you successfully configured a workload identity pool and connected it to a Google service account, your Bitrise builds can exchange tokens with GCP. You can:

  • Fetch the token with Get OIDC Identity Token Step, then perform the credential exchange with a script.

  • Use the Authenticate with GCP Step to handle the whole process.

Using the Get OIDC Identity token Step

The Get OIDC Identity Token Step exposes an Environment Variable called BITRISE_IDENTITY_TOKEN. You can use this Env Var in a script to exhange credentials with AWS.

  1. Open the Workflow Editor on Bitrise.

  2. Add the Get OIDC Identity Token Step to your Workflow.

  3. Use the BITRISE_IDENTITY_TOKEN Environment Variable: write it to a file and update the client library configuration file to reference the file containing the Env Var. You can set this up in a Script Step:

    tmpfile="$(mktemp)"       
    printf '%s' "$BITRISE_IDENTITY_TOKEN" > "$tmpfile"
    
    # Replace the token path in client library configuration
    
    gcloud auth login --cred-file=/path/to/updated-client-library-config.json
    gcloud auth list

    After, the gcloud CLI will automatically pick them up and use them. Any kind of action through the CLI will just simply work.

Using the Authenticate with GCP Step

  1. Open the Workflow Editor on Bitrise.

  2. Add the Authenticate with GCP Step to your Workflow.

  3. Set the Client config and the Token audience inputs:

    • The token audience should match the allowed audience you set when configuring the workload identity pool on Google Cloud.

    • The Client config input should point to the file you downloaded at the end of the process.

The Step will expose the credentials in the right format. After that, any kind of action through the gcloud CLI will simply work.