Repository files navigation

Reproducible Github Workflow OpenID Connect for GCP using Terraform

The prerequisites to executing this setup include:

• Terraform CLI
• GCP Project
• gcloud CLI

Good how-to on using terraform with GCP is locatedhere.

To acquire the reproducible Github Workflow OpenID Connect setup for GCP you can either clone the Repo using SSH:

git clone git@github.com:mchmarny/oidc-for-gcp-using-terraform.git

or using HTTP:

git clone https://github.com/mchmarny/oidc-for-gcp-using-terraform.git

Once you've cloned the setup repo, navigate inside of that cloned directory and initialize Terraform

Make sure to authenticate to GCP usinggcloud auth application-default login if you haven't done it already.

terraform init

Note, this flow uses the default, local terraform state. Make sure you do not check the state files into your source control (see.gitignore), or consider using persistent state provider like GCS.

To configure Github Workflow OpenID Connect setup for GCP apply the cloned configuration:

terraform apply

When promoted, provide the 2 required variables:

• project_id is the GCP project ID (not the name) which you want to target from your GitHub Action.
• git_repo is the username/repo combination in which you GitHub Actions will be executing

You can review each one fo the*.tf files for content. When you confirmyes at the final prompt, the main artifacts created by this setup in the GCP project defined by theproject_id variable include:

• Enablement of the required GCP APIs
  • servicecontrol.googleapis.com
  • containerregistry.googleapis.com
  • iam.googleapis.com
  • iamcredentials.googleapis.com
  • servicemanagement.googleapis.com
  • storage-api.googleapis.com
• Creation ofgithub-actions-user service account which the GitHub Action will impersonate when publishing images into GCR, and binding that account to the two required role:
  • roles/storage.objectCreator
  • roles/storage.objectViewer
• Creation of the workload identity pool:github-pool, and GitHub repo-level pool provider:github-provider
• Finally, creation of the IAM policy bindings to the service account resources created by GitHub identify for the specific GitHub repository defined by thegit_repo variable

The result each execution of the above defined configuration will include 3 GitHub repo configuration properties:

• PROJECT_ID which is the project ID in which you setup the workload identity federation
• SERVICE_ACCOUNT which is the IAM service account your GitHub Action workflows will use to push images into GCR (e.g.github-action-publisher@<project_id>.iam.gserviceaccount.com)
• IDENTITY_PROVIDER which si the workflow identity provider ID you must use lng with the above service account to connect to GCP (e.g.projects/<project_number>/locations/global/workloadIdentityPools/github-pool/providers/github-provider)

Depending on your tolerance, you may be OK using all 3 of these parameters in your GitHub Actions workflow in plain-text. In most cases, however, you will probably create GitHubsecrets in your repository to inject them into your workflow at runtime.

With the Workload Identity Federation configured yur workflow can now establish delegated trust relationship to the narrowly scoped set of permissions in GCP. Thegoogle-github-actions/auth includes many examples usinggcloud in your workflow.

In this post I'm going to focus onGo-specific configuration usingko, (a super simple and fast container image builder for Go apps) to build and publishing images intoGCR. The full workflow is availablehere. The key steps include:

First, in order create OIDC tokens, the GitHub Actions will need additional permissions. In addition to regularcontent read, the workflow will alsoid-token write.

jobs:push:runs-on:ubuntu-latestpermissions:contents:readid-token:writesteps:

In order to push images to GCR, the workflow will need to first authenticate to GCP. Google has an action just for that that can be configured to generate OAuth 2.0 Access Token. To do this you will need to set thetoken_format toaccess_token. Additionally, this step will use the workload identity provider and service account secrets we configured above:

    -id:authname:Get GCP tokenuses:google-github-actions/auth@v0.5.0with:token_format:"access_token"workload_identity_provider:${{ secrets.IDENTITY_PROVIDER }}service_account:${{ secrets.SERVICE_ACCOUNT }}

Ko is the fastest way of creating container images in Go without Docker. All we need to do is install it and login to GCR with the access token created by theauth step above:

    -name:Install Kouses:imjasonh/setup-ko@v0.4with:version:tip            -name:Login With korun:|        ko login gcr.io --username=oauth2accesstoken --password=${{ steps.auth.outputs.access_token }}

With ko logged in, now you can build and publish the image. A few things to highlight here.ko build (pkapublish) will build and publish container images from the given path. The--image-refs flag will output the digest of the published image to the provided file, and the--bare allows us to define the full image URL using theKO_DOCKER_REPO environment variable.

In addition to this we will set the previously exportedRELEASE_VERSION environment variable to bothversion field in themain.go file and set it as a tag on the image.

    -name:Publish Imagerun:|        ko build ./cmd/ --image-refs ./image-digest --bare --tags ${{ env.RELEASE_VERSION }},latestenv:KO_DOCKER_REPO:gcr.io/${{ secrets.PROJECT_ID }}/restmeGOFLAGS:"-ldflags=-X=main.version=${{ env.RELEASE_VERSION }}"

Once the image is published, we can also sign and verify the published image in GCR usingcosign.

    -name:Install Cosignuses:sigstore/cosign-installer@mainwith:cosign-release:v1.4.1

The benefit of combiningko andcosign is that we can use the image digest output into a local file byko by providing its path using--force flag in thecosign sign command.

With the v1.4 release of cosign, you set thCOSIGN_EXPERIMENTAL variable to push the data into GCR.

    -name:Sign Imagerun:|        cosign sign --force $(cat ./image-digest)env:COSIGN_EXPERIMENTAL:1

To clean all the resources provisioned by this setup run:

terraform destroy