How to use Github Actions with Google's Workload Identity Federation

You can build and deploy code (CI/CD) to Google Cloud using GitHub Actions by uploading a service account key to GitHub. But that opens one more spot of vulnerability and it makes it hard to rotate keys. Some organizations even forbid exporting service account keys for that reason.
Let's fix that! If you use Google's Workload Identity Federation, you can still build and deploy with GitHub Actions, but you don't have to upload a sensitive key to GitHub. In this video Luka and Martin will show you how.
Check out more episodes of Serverless Expeditions → goo.gle/ServerlessExpeditions
Subscribe to Google Cloud Tech → goo.gle/GoogleCloudTech
#ServerlessExpeditions​

[@googlecloudtech]

Subscribe to Google Cloud Tech → goo.gle/GoogleCloudTech

[@barclayiversen376]

Excellent video, this was one of the few things chatGPT couldn't clearly explain how to set up.

[@TheMomander]

Happy to hear it was useful. Sometimes that human touch is needed.

[@KanishkaHalder-f8k]

Great stuff. Would be great if you guys could link the mentioned documentation here for reference. 🥂

[@ravichanderkt326]

Thanks for the wonderful session, it really starts my monday with new learning, will be waiting for more security focused videos.

[@TheMomander]

Happy to hear that! I agree with you that security is important.

[@sabinadhikari2643]

Now the UI has changed and there are many other options that we need to fill to Grant Access. Please make a video on that

[@gb-wj7dg]

The documentation on this is kind of lacking. I've tried every variation of setup I can find online and still get a "Permission storage.objects.list denied on resource" error every single time. My service account is properly setup and has the correct permissions/access to my bucket and is connected to my pool. My github secrets are the correct email and provider and they're setup in my workflow file which runs correctly each time. However permission is still denied. I've gone through dozens of stackoverflow and similar threads of people experiencing the same error, tried their solutions and nothing. Pretty frustrating experience when all I'm trying to do is read a couple of CSV files for an app so I don't have to manually download and push them once a week

[@TheMomander]

Sorry to hear you're getting error messages. I sometimes run into similar errors, especially with Cloud Storage. The strategy that has worked best for me is to temporarily make the service account "Editor" of the project, make sure it works, and then dial back the permissions.

[@gb-wj7dg]

@@TheMomander thanks for the tip, hadn't seen this specfic role recommended. unfortunately this still produced the same error

[@TheMomander]

@@gb-wj7dg Sorry to hear it didn't work. Well, at least we know it's not something wrong with the permissions of the service account. If I were you, I'd ask the Google Cloud sub-reddit next. I have seen developers discuss WIF there before.

[@gb-wj7dg]

@@TheMomander ok thank you, I'll try my luck there

[@princejeetsingh3984]

Does the "workload identity provider ID" and "service account" have to be a secret? Can they just be plain text? Would be nice to know the security impications of that?
Thanks for the video :)

[@lukapuka1296]

While they both aren't considered nor contain "secrets" (as in an attacker acquiring them wouldn't be able to do anything in the immediate) my recommendation would still be to treat them sensitively. Both the "workload identity provider id" with project number & the pool id for the given project and SA email itself I would say are sensitive pieces of information.

[@lukapuka1296]

Great questions btw!

[@princejeetsingh3984]

Thank you :)

[@oscarantoniosanchezpena7903]

Excelente, de mucha ayuda

[@vinayakumarbendi4145]

@googlecloudtech Is it possible to access Google Cloud assets in one account from another Google Cloud account (belonging to another organisation)? For this use case, when creating a workload identity pool can OIDC be used? If OIDC can be used, what values to use as Provider ID and Issuer (URL) in case of Google Cloud?

[@ashotmnatsakanyan1784]

Can you make a video on publishing the npm package to the Google Artifact repository?
Also, this video is a little bit outdated, and Google documentation is only for the lawyer not for developers. Can you point to the relevant video?

[@netroxtechnologies1268]

Beautiful presentation Martin and Luka, how can i get the previous video on service account key?

[@TheMomander]

Happy to hear you found the video useful. To find the other video, do a TH-cam search for "How to deploy Cloud Run services with GitHub Actions".

[@RFsalman]

The UI shown here is different from the current one,
In the grant access with service account impersonation menu, i need to fill in:
Select principals (identities that can access the service account):
attribute name: ...
attribute value:...
What should i fill this with ?

[@peterjkirubagaran]

is there a document to go through all the provider mapping options?

[@TheMomander]

I don't fully understand your question, but if you search for "google cloud workload identity federation" you will get some pretty good results. Do those docs have what you need? If not, please elaborate on what you are looking for and I will try to find it.

[@bornok1040]

Can Google's Workload Identity Federation be used if I want my back-end application which is running outside the Google Cloud to access Google APIs such as Calendar API? If not, what's the best solution for doing this in production environment? I don't want to use Service access key.

[@lukapuka1296]

I typically see Workload Identity Federation used to authenticate workloads looking to access GCP services (not necessarily RESTful API's directly) without storing long lived keys. A close example might be your back-end application (with the assumption that it supports OIDC) using WIF to authenticate to/invoke a private Cloud Run Service (which in theory could have an endpoint deployed to access the Workspace Calendar API).

[@lokeshmirchi6477]

Can we use the WIF approach for Firebase services, such as deploying Firebase Hosting and Firebase functions with GitHub Actions?

[@TheMomander]

Sorry, I don't believe that's possible yet.

[@sujayjha2690]

I am using terraform module in one repository in github and manifest in another repository. When try to run terraform it is unable to authorize module. How can we achieve this with workload identity federation?

[@lukapuka1296]

I'm not entirely sure I follow the scenario. A few questions I have; How is the terraform module in repo one being used, within a GitHub Actions Workflow file? And how does the manifest in the other repository relate?

[@user-sm9kx4wj4h]

When i try to grant access to service account, the option for "All identites in the pool" under select principal is not there.

[@lukapuka1296]

If you are getting that display it means that when attributes are setup in the Provider setup (ie. attribute.repository), you'll need to select that given attribute and input the matching value (from the GitHub OIDC token) that you'd expect. So if I select the "repository" attribute and the value I input is "MyUser/MyRepo" in the Grant Access step, impersonation will only be successful if the OIDC token exchanged in the GitHub Actions workflow contains that repository value. Essentially this step ensures that only identities with a certain value can authenticate.

[@andresaguilar3996]

outdated