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

Подписаться 1,1 млн

Просмотров 11 тыс.

50% 1

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

Наука

Опубликовано:

28 июн 2023

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 33

@googlecloudtech Год назад

Subscribe to Google Cloud Tech → goo.gle/GoogleCloudTech

@barclayiversen376 6 месяцев назад

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

@TheMomander 6 месяцев назад

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

@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.

@KanishkaHalder-f8k День назад

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

@oscarantoniosanchezpena7903 10 месяцев назад

Excelente, de mucha ayuda

@sabinadhikari2643 2 месяца назад

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 9 месяцев назад

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 9 месяцев назад

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 9 месяцев назад

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

@TheMomander 9 месяцев назад

@@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 9 месяцев назад

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

@vinayakumarbendi4145 5 месяцев назад

@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?

@princejeetsingh3984 11 месяцев назад

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 11 месяцев назад

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 11 месяцев назад

Great questions btw!

@princejeetsingh3984 11 месяцев назад

Thank you :)

@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 ?

@netroxtechnologies1268 9 месяцев назад

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

@TheMomander 9 месяцев назад

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

@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.

@ashotmnatsakanyan1784 5 месяцев назад

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?

@bornok1040 10 месяцев назад

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 10 месяцев назад

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 9 месяцев назад

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

@TheMomander 9 месяцев назад

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

@sujayjha2690 10 месяцев назад

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 10 месяцев назад

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 7 месяцев назад

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

@lukapuka1296 7 месяцев назад

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.