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

Key Takeaways

Luca Martin great to see you how far are things well thank you in a previous video you showed us how to set up a cscd pipeline in GitHub actions using service account keys but you also said there was a better way of doing it yeah exporting service account Keys leads to a lot more work for example when you need to rotate the keys that's where workload identity Federation comes in but we must use a key right how else would Google now that the call from GitHub is legit the magic is in the implementation details let's take a closer look [Music] alright we're trying to eliminate exported service account keys but how can GitHub deploy code securely to Google Cloud without a service account key well if someone had my car key they could drive my car regardless of whether I allow it or not yeah that makes sense Luca and that poses a lot of security concerns right exactly and even though GitHub is securely storing that service account key it adds one more place of vulnerability plus the key is long-lipped right right and many organizations even forbid the export of keys for that very reason right fortunately we now have workload identity Federation which means we don't have to rely on Keys anymore how does that work well with workload identity Federation when the unknown actor tries to use my car key in the analogy earlier I am able to decide if the car will unlock or not so instead of my car key being open to any user out there when the key is clicked a message is first sent that describes their identity like who I am or if I'm old enough to drive for example exactly when the car key is clicked a message is sent to a service that I control I can set it up first to only trust messages coming from certain car keys or to only allow users that meet given condition based on information in the message itself great this seems promising look up uh what happens next so should the authorization succeed the service will send a token back to my car key enabling the actor to use it on behalf of me the token itself however is only single use got it and each time the key is used the same flow takes place sounds like I won't have to worry about long-lived service account Keys anymore exactly Martin and we have some best practices for workload identity Federation setup as well let's get into it alright Martin we are going to start by setting up workload identity Federation through the cloud UI perfect and I presume we can always go back and automate this setup with gcloud commands at the command line right later exactly we even have all the commands you need for setup here in the auth action readme that's great uh now what's the first step the first thing you'll need to get started is enable the IAM credentials API in the Google Cloud console sounds good Luca let me do so real quick all right should be good to go there uh what's next awesome so next we're going to work through configuring a workload identity pool and provider let's search for workload identity Federation in the Google Cloud console sounds good Luca looks like I'll need to select the new workload provider and pool option that is correct there will be a few things we'll need to do here the first will be to create an identity pool which manages a group of identities and their access to Google Cloud resources thinking back to our analogy earlier the pool would be the key ring our car key is on ah okay that makes sense so the pool just manages these identities and each of the identities or keys on the keyring would be a provider like GitHub for example exactly Martin in our case GitHub but it can be entity any identity provider that supports oidc oh any provider do you have an example of what you might be able to do here Beyond GitHub of course Mark a good example might be a service running on an AWS ec2 instance accessing unstructured data from cloud storage go audit to make sure I'm understanding then workload identity Federation would allow my app on Amazon web services to make a validated request to my Google Cloud Storage bucket and if valid it would have short-lived access to that bucket that is exactly right Martin and all without the need to export along the key beautiful it's all falling into place Luca so to get started let me create a pool I'll name this GitHub GitHub actions Cloud run workflow here to be specific allow the provider to this pool I assume that will be GitHub that's correct let's choose the oidc and fill in the information for GitHub perfect filling that now uh oh what's this is your url field all about Luca so that'll be a specific URL where GitHub issues the oidc token let's check github's documentation for that okay uh check-in get github's documentation ah there it is found it uh copy that update that field now all right uh not what are these attribute and condition inputs here great question so the attribute mapping flag is how we map claims from the oidc token that GitHub provides two attributes within Google Cloud got it so those conditions in the car example that could be like is the driver 18 or older are they a family member and so on and that information would be provided when the user clicked the car key what sort of information can GitHub provide here there's a fair amount that GitHub will provide you Martin and GitHub has a full list but to tease out just a few the repository workflow ID actor and event name are all common options so I could for example restrict authentication based off of the repo name to further look down access exactly the only thing we will need to do is map them to attributes within Google Cloud let's add a few mappings so the first mapping will be the required google.subject which we can set to the subject for the oidc token all right adding it now second we can add a few values one for the actor in case we want to restrict access down to the individual person and the other for the repository okay adding that as well now what about the attribute conditions here uh how do I make sure authentication is restricted to the right repository great question and we do so through the attribute condition flag the condition can be a common expression language statement or an IAM policy I personally like to use Cel it's really simple to use and great for evaluating expressions plus we have great docs on it as well gotcha what would the common expression language of Cl statement be in this case so it's going to be something really simple let's add a CL statement setting assertion.repository to the name of your repo Mart great doing that now the auth action provides a lot of flexibility huh it really does uh okay Luca is this all I need to do to use workload.nc Federation with GitHub the last step Martin would be to allow the workload identity provider to impersonate the service account you use to deploy the cloud run service oh right and so I need to explicitly specify what service account will be impersonated so what service account will this run on on the Google Cloud side that makes sense but but how do I do it yeah so once the pool and provider are created we can click into the pool and Grant access to a specific service account okay I'll click into the pool now so this service account uh look at this will be one with access to our Cloud run resources that's correct great uh looks like everything is set up and ready in Google Cloud uh let's go and update GitHub so let's say all right I'm in the actions workflow file in GitHub and I see the original auth action the one we set up last episode so what should I change here so the changes are actually quite simple instead of the service account key we are going to add two new parameters the workflow identity provider and the service account to impersonate got it I'm going to fill these in with GitHub secrets that I will create shortly so one quick question here okay what's the format of the workflow workload identity Federation provider so the format of the provider includes the Google Cloud project number the name of the workload identity pool and the name of the provider we can also use gcloud commands to fetch the full provider programmatically as well great just fetch the workload identity provider we really need a shorter name for it I know that's a lot to say it's a lot to say all right anyway so so the this provider and the service account are saved as secrets in GitHub now anything else before deploying nope it all seems set up Martin perfect let me try out the new say CD workflow I'll make a minor change to my code here and let's see if it redeploys my service let's do it so as the workflow runs Martin you'll notice that the auth action step exports temporary credentials to our environment awesome and looks like my server is redeployed to Cloud run and all without a service account key it's pretty great right all right Luca so with these changes anytime my GitHub action workflow runs the workflow is validated as coming from my Repository and a single use key is provisioned for the cloud run deployment right exactly Martin we are no longer letting just about anyone who has access to our keys use our car that is now Locked Down based on conditions we control plus there is no need to export long-lived credentials which means our workflow is more secure brilliant and thank you everyone for tuning in if you like this video please subscribe below and leave a comment also let us know if you have any questions for Luca about what we covered in this video and if you're interested in more actions managed by the Google GitHub actions team check out their org in the description below until next time bye thank you