Still using sensitive service account keys in your GitLab repository? Want to enhance the security of your CI/CD pipelines? In this blog post, I will show you the process of authenticating your GitLab CI/CD pipelines to Google Cloud using OpenID Connect (OIDC).

By leveraging OIDC, you can eliminate the need to store sensitive credentials in your repository, significantly reducing the risk of unauthorized access. We’ll explore how to set up Google Cloud Service Accounts, Workload Identity Pools, and configure GitLab CI/CD to seamlessly authenticate with Google Cloud.

OpenID Connect is an identity layer on top of the OAuth 2.0 protocol. It allows third-party applications to verify the identity of end-users or in our case a Service Account on Google Cloud.

Google Cloud Service Account and Workload Identity

Within Google Cloud you need to create a Service Account and a Workload Identity Pool with a Workload Identity Provider to authenticate to Google Cloud with OpenID Connect.

This Terraform project explains how to set this up and creates the required Google Cloud resources.

GitLab CI/CD

You can use the GitLab component found here: GitLab CI/CD project to authenticate to Google Cloud in your pipeline. Or find it in the GitLab CI/CD Catalog under the name google-oidc-authentication. In the README you will find the steps to set up the GitLab component in your GitLab CI/CD.

If you don’t want to use the component created by me, you can copy the code from the template.yml and implement it in your own pipeline or self managed GitLab component.

How does the component work?

The component uses the gcloud SDK to authenticate to Google Cloud with OpenID Connect. It requires the Service Account and Workload Identity Pool with Workload Identity Provider created by the Terraform project.

The GitLab component job (found here template.yml) creates a gcloud configuration file called .ci_job_jwt_file in this file all the needed variables are stored to authenticate to Google Cloud. This file is outputted as an artifact and can be used in the next job to authenticate to Google Cloud.

The artifacts configuration in the template.yml file looks like this:

  artifacts:
    expire_in: $[[ inputs.expire_in ]] seconds
    access: none
    paths:
      - $CI_PROJECT_DIR/_gcp_auth/

To prevent users downloading the artifact access is set to ’none’ and therefore, not available for download by anyone.

As an example the next job can use the gcloud configuration file to authenticate to Google Cloud. To make sure the next job waits for the authentication job to finish, you can use the needs keyword in the next job.

deploy:
  needs: [gcloud-auth]

A full GitLab CI Terraform/OpenTofu example:

Below you will find an example of a .gitlab-ci.yml file that uses the GitLab component and the OpenTofu component to authenticate to Google Cloud and deploy a Terraform project.

variables:
  GITLAB_TOFU_ROOT_DIR: ${CI_PROJECT_DIR}
  GITLAB_TOFU_STATE_NAME: default

include:
  - component: gitlab.com/components/opentofu/job-templates@~latest
    inputs:
      version: latest
      opentofu_version: 1.6.2
  - component: $CI_SERVER_FQDN/tiborhercz/google-oidc-auth/template@<VERSION>
    inputs:
      gcp_project_id: $GOOGLE_CLOUD_PROJECT
      gcp_service_account: $GOOGLE_SERVICE_ACCOUNT_EMAIL
      gcp_workload_identity_provider: $GOOGLE_WORKLOAD_IDENTITY_PROVIDER

plan:
  stage: deploy
  needs: [gcloud-auth]
  extends: [.opentofu:plan]
  variables:
    GOOGLE_APPLICATION_CREDENTIALS: $CI_PROJECT_DIR/_gcp_auth/.gcp_temp_cred.json

apply:
  stage: deploy
  needs: [gcloud-auth, plan]
  extends: [.opentofu:apply]
  variables:
    GOOGLE_APPLICATION_CREDENTIALS: $CI_PROJECT_DIR/_gcp_auth/.gcp_temp_cred.json
    GITLAB_TOFU_PLAN_CACHE: $GITLAB_TOFU_ROOT_DIR/plan.cache

The Terraform provider uses the temporary credentials file stored in the variable GOOGLE_APPLICATION_CREDENTIALS to authenticate to Google Cloud.

Conclusion

By following this guide, you’ve successfully learned how to securely authenticate GitLab CI/CD pipelines to Google Cloud using OpenID Connect. This approach eliminates the need to store sensitive service account keys in your GitLab repository, enhancing overall security and reducing the risk of credential leaks.

In this blog I have provided you with two options for setting up the authentication:

1. Utilize the pre-built GitLab component: This simplifies the process by offering a ready-made component you can integrate into your pipeline. Instructions for using it can be found in the provided GitLab repository link.
2. Implement the code yourself: If you prefer more control over the authentication process, you can copy the code from the provided template file and adapt it to your specific needs.

Link to the official GitLab documentation Configure OpenID Connect with GCP Workload Identity Federation