How to use Github Actions with Google's Workload Identity Federation
Google Cloud Tech
11 min, 33 sec
The video discusses setting up a CI/CD pipeline in GitHub actions using service account keys and provides a detailed explanation and setup guide for a more secure method, using Workload Identity Federation.
Summary
- Workload Identity Federation eliminates the need for service account keys, reducing security risks related to key rotation and potential vulnerabilities.
- It works by having an identity (like GitHub) send an authentication message to a service, which sends back a single-use token if the conditions are met.
- The setup process involves enabling the IAM credentials API in the Google Cloud Console, creating a workload identity pool and provider, and specifying the service account to impersonate.
- Attribute mappings and conditions can be added to further control access.
- GitHub can be updated to use Workload Identity Federation by adding parameters to the auth action step, saving them as secrets, and making minor code changes.
Chapter 1
Martin and Luca discuss setting up a CI/CD pipeline in GitHub actions using service account keys and introduce a better method using Workload Identity Federation.
- Luca explains that exporting service account keys leads to more work, such as rotating the keys.
- Through Workload Identity Federation, there is no need to rely on keys.
Chapter 2
Luca explains how Workload Identity Federation works, comparing it to a car key being used by an authorized person.
- When an unknown actor tries to use the key, the car owner can decide whether the car will unlock or not.
- A message is first sent that describes the identity of the actor, like their age or identity.
- If the authorization is successful, a token is sent back to the actor, allowing them to use the key on behalf of the owner.
- Each time the key is used, the same flow takes place.
Chapter 3
Luca guides Martin through the process of setting up Workload Identity Federation, including enabling the IAM credentials API, creating an identity pool and provider, and specifying the service account to impersonate.
- The identity pool manages a group of identities and their access to Google Cloud resources.
- The identities or keys on the keyring would be a provider like GitHub.
- The attribute mapping flag maps claims from the OIDC token that GitHub provides to attributes within Google Cloud.
- The attribute condition flag can be a Common Expression Language statement or an IAM policy.
Chapter 4
Martin updates GitHub to use Workload Identity Federation by adding parameters to the auth action step and saving them as secrets.
- The new parameters include the workload identity provider and the service account to impersonate.
- The format of the provider includes the Google Cloud project number, the name of the workload identity pool, and the name of the provider.
- The service account is one with access to the Cloud Run resources.
Chapter 5
Luca and Martin conclude the video by summarizing the benefits of using Workload Identity Federation and encouraging viewers to leave a comment.
- Workload Identity Federation provides more control over conditions and eliminates the need for long-lived credentials, making the workflow more secure.