CD with Google Cloud Run, GitHub Actions, Artifact Registry, & WIF

Tushar Roy Chowdhury
6 min readJul 18, 2023

These days CI/CD is very much important to integrate & deploy an application to the cloud without doing repetitive work. And I am going to share a very basic CD (Continuous Delivery) using GCP. So let’s Jump in.

I am assuming you have all the privileges to the projects & resources — Clou Run, Artifact Registry, Secret Service, Service Accounts, Roles, & Workload Identity Pools.

First of all, let’s write down the steps

  1. Create Workload Identity Pool & Provider.
  2. Create custom roles.
  3. Create a service account and add custom roles as well as pre-defined roles. After that add the principal of the workload identity pool and assign roles as well.
  4. Create a repository in the Artifact registry.
  5. Add secrets to the Secret Manager.
  6. Launch a service in the cloud run.
  7. Add secrets & variables in the GitHub repository.
  8. Write down the code for Continuous Delivery(CD).
  9. Push to the master branch to execute the deployment process or do it manually from the Github Actions tab in the repository.
  10. Take a rest.

Now let’s talk about the details of these steps.

Step-1: IAM & Admin > Worload Identity Federation.

Click a button name Create Pool which is located at the top of the page.

  1. Create a pool with a Name & description. Press Continue.
  2. Create a provider. In our case, it will be OIDC (OpenID Connect) as we will going to use GitHub as our CD tool (Configure OIDC).
  3. Configure provider attributes. These attributes are provided by the external identity (GitHub OIDC Token) and the issued token will contain these attributes for authentication. The flow of checking the attributes is something like this — Whenever we will start our CD execution flow, first GCP will fetch those attributes from GitHub & send them back to GitHub with our pre-defined attributes. And will try to match those mapping values from the access token (More Details).
  4. Add attribute conditions. This is not mandatory but you can restrict it. Such as specific repositories. You can add this by writing - assertion.repository==’username/repository_name’. This provider will only accept requests from this repository. Now press save & it will redirect to the details page of the pool. See Image-

As you can see there are 3 red boxes. In the tab name CONNECTED SERVICE ACCOUNTS where the list is empty and we are going to add a service account in the 3rd step. To connect a service account we will going to grant access by using this IAM principal & assigning a role name Workload Identity User to impersonate the service account.

Step-2: IAM & Admin > Roles. Press CREATE ROLE button.

It is better to give minimal permissions to a service account. To follow this approach we will going to create a custom role. In our case, we need these two permissions and name that role whatever you want.

// Name of the role - Custom Secret Manager Secret Accessor
// Permissions
iam.serviceAccounts.actAs
secretmanager.versions.access

Step-3: IAM & Admin > Service Accounts. Press CREATE SERVICE ACCOUNT.

  1. Fill up the Service account details and press CREATE AND CONTINUE.
  2. Add roles for the service account to access this project. We should add limited roles for that. Roles are — Artifact Registry Writer, Cloud Run Developer & Custom Secret Manager Secret Accessor.
  3. You can also add the user’s email, Google groups, etc(Optional).
  4. Press Done. And it will redirect to the service account list page. By selecting this newly created account (select Checkbox), we will click the MANAGE ACCESS button which is located at the top.
  5. A right modal will appear where we can see the list of roles/principals. Then click on ADD PRINCIPAL button.
  6. Copy the IAM principal from the Workload Identity Pools as I have already mentioned in STEP-1. Paste it in the principal input box and assign a role name — Workload Identity User.
  7. Press the Save button. Go back to that pool details & select the CONNECTED SERVICE ACCOUNT tab. We should see the new service account.

Step-4: Create a repository in Artifact Registry.

To deploy the application in the Cloud Run, a container image is required. To do that we are going to create one & every time it will add a new image whenever a new build & push trigger from the CD pipeline. Now fill up the info-

  1. Give a proper name for the repository.
  2. I am going to select the Docker format because my dummy application is Docker container based. Use your own format if you have a different one.
  3. Keep the Standard Mode or change it according to your need.
  4. The Location type is very important for the CD. Because we will be going to use this location to build and push a new image with a tag.
  5. Keep the rest of the things as it is for now and press CREATE button.

Step-5: A better way to create secrets for an application.

It is always good to keep the value of secret variables visible not for all the accounts. To do that we can use Secret Manager. It is very easy to maintain & only shows the name & version of that secret variable. For more details — Secret Manager Documentation

Step-6: Prepare a service in the cloud run.

  1. Go to the Cloud Run & press CREATE SERVICE.
  2. Select option — Deploy one revision & for now select a test sample image. It will be replaced later anyway.
  3. Give a proper service name & also set a region. Here the region is important because it will be used in the CD pipeline.
  4. Keeps the things as it is. For now, select Allow unauthenticated invocations (for public view) or you can change to Require authentication option (Need to set Authorized users for that).
  5. Expand the Container, Networking, and Security part. In the container tab, you can change the port. In my case, it is 4000.
  6. Keep things as it is and go to the Secrets section. We have already created the secrets in step-5 and now we are going to add them here as a secret reference.
  7. Select a secret reference from the drop-down list one by one. The reference method should be Exposed as an environment variable otherwise you have to mount a volume for that.
  8. In the Environment variables section add a name & version. Remember, the name of the variable should be equal to the env variables that you used in your application.
  9. Now hit the CREATE button.

Step-7: Add secrets & variables in the GitHub repository.

  1. Go to your repository & select the settings tab.
  2. Select Secrets and Variables > Actions menu.
  3. To add secrets, click the New Repository secret button and give Name & Secret. In my case, I don’t want to reveal the WIP(workload identity provider) & Service account when CD will start to execute. Check out this doc for the format of WIP.
  4. In the Variables tab, you can add your variables by clicking the New Repository variable.

Step-8: Code for Continous delivery.

This file will trigger when we merge code to the master. Let me break down the steps-

  1. After checking out to the repository using actions/checkout@v3, it will move to the Google Auth part.
  2. This auth part will authenticate the Google Cloud with the help of impersonated account. After the successful authentication, it will give the token as an output.
  3. That output will be used as a password to login into the Artifact Registry. After that, it will build & push to the repository.
  4. In that final step, it will deploy that image to the Cloud Run.

Step-9: Push the code to your branch.

If you added the master/relevant branch for your CD pipeline you can push into that branch. It should start our CD script & will deploy successfully.

Step-10: Take a Rest.

If you made this far then I should thank you for your attention. You can check the full code of my dummy application. Dummy-Food-APP

If you have any doubt or want to add something I am happy to get it from you.

Thank You…

--

--

Tushar Roy Chowdhury

I am a passionate programmer and always keep eye on new technologies and scrutinize them until getting into shape.