An overview of identity federation for external workloads is given in this document. Without utilising a service account key, you can give on-premises or multi-cloud workloads access to Google Cloud resources by leveraging identity federation.

You can utilise identity federation with SAML 2.0, Microsoft Azure, Amazon Web Services (AWS), or any identity provider that supports OpenID Connect (OIDC).

Why identity federation?

Traditionally, apps running outside of Google Cloud could access Google Cloud services via service account keys. Service account keys, however, are strong credentials and might pose a security concern if they are not properly handled.

By utilising identity federation, you can grant external identities IAM roles, such as the capacity to mimic service accounts. With this strategy, service account keys' maintenance and security burdens are removed.

The user is requesting that the Github Provider be trusted in this. Workload Identity Pool, Workload Identity Provider, and IAMs are created to do this. Each of these should be considered separately.

Workload Identity Pool:

To structure and manage external identities, use workload identity pools. It is advised to establish a fresh pool for other non-Google cloud environments. To generate the same, use the command below:

gcloud iam workload-identity-pools create github-wif-pool --location="global" --project <project_id>

Workload Identity Provider:

The relationship between an external identity, such as Github, and Google Cloud is described by the term "workload identity provider." In essence, it creates a trust relationship between external identity and GCP. By applying the properties from an external token to a Google token, it offers attribute mapping. This enables IAM to authorise access to Google Cloud resources using tokens from outside providers. In essence, this is a method of converting foreign tokens into tokens that have GCP equivalents. To generate the same, use the command below:

gcloud iam workload-identity-pools providers create-oidc githubwif \
--location="global" --workload-identity-pool="github-wif-pool"  \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="attribute.actor=assertion.actor,google.subject=assertion.sub,attribute.repository=assertion.repository" \ --project <project_id>

Service Account and IAMs:

A service account with the necessary permissions is required. WIF will use this service account to commit fraud. Additionally, we provide capabilities to enable impersonating the appropriate Service Account during authentication using the identity provided by the Workload Identity Provider. It enables Github activity to obtain a token by pretending to be the service account. Please take note of the member name's use of the attribute "repository". It allows IAM to authenticate only requests coming from the repository ‘AdityaRai/gcp-wif’. If we have not used this, then all the github repos which are using a specific workload identity provider can authenticate against IAM. Below command can be used to create the same:

gcloud iam service-accounts create test-wif \
--display-name="Service account used by WIF POC" \
--project <project_id>

gcloud projects add-iam-policy-binding <project_id> \
--member='serviceAccount:test-wif@<project_id>.iam.gserviceaccount.com' \
--role="roles/compute.viewer"
gcloud iam service-accounts add-iam-policy-binding test-wif@<project_id>.iam.gserviceaccount.com \
--project=<project_id> \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/github-wif-pool/attribute.repository/AdityaRai/gcp-wif"

Additionally, there are options to limit login from particular branches. To do that, we must apply the following principal.

principal://iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/POOL_ID/subject/repo:AdityaRAi/gcp-wif:ref:refs/heads/main

This ensures that only the main branch of repo AdityaRai/gcp-wif can authenticate.