Sponsored

GCP - Federation Abuse

OIDC - Github Actions Abuse

GCP

In order to give access to the Github Actions from a Github repo to a GCP service account the following steps are needed.[1][4]

  • Create the Service Account to access from github actions with the desired permissions:[8][9]
projectId=FIXME
gcloud config set project $projectId

# Create the Service Account
gcloud iam service-accounts create "github-demo-sa"
saId="github-demo-sa@${projectId}.iam.gserviceaccount.com"

# Enable the IAM Credentials API
gcloud services enable iamcredentials.googleapis.com

# Give permissions to SA

gcloud projects add-iam-policy-binding $projectId \
    --member="serviceAccount:$saId" \
    --role="roles/iam.securityReviewer"

[!NOTE] Before configuring Workload Identity Federation, verify that the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs required by Google's deployment-pipeline guidance are enabled; this example explicitly enables only iamcredentials.googleapis.com.[1]

  • Generate a new workload identity pool:[1][6]
# Create a Workload Identity Pool
poolName=wi-pool

gcloud iam workload-identity-pools create $poolName \
  --location global \
  --display-name $poolName

poolId=$(gcloud iam workload-identity-pools describe $poolName \
  --location global \
  --format='get(name)')
  • Generate a new workload identity pool OIDC provider that trusts github actions (by org/repo name in this scenario):[1][4][5][6]
attributeMappingScope=repository # could be sub (GitHub repository and branch) or repository_owner (GitHub organization)

gcloud iam workload-identity-pools providers create-oidc $poolName \
  --location global \
  --workload-identity-pool $poolName \
  --display-name $poolName \
  --attribute-mapping "google.subject=assertion.${attributeMappingScope},attribute.actor=assertion.actor,attribute.aud=assertion.aud,attribute.repository=assertion.repository" \
  --issuer-uri "https://token.actions.githubusercontent.com"

providerId=$(gcloud iam workload-identity-pools providers describe $poolName \
  --location global \
  --workload-identity-pool $poolName \
  --format='get(name)')

[!NOTE] The provider above maps GitHub claims but does not set a provider-level --attribute-condition. The subsequent service-account binding is repository-scoped, but Google recommends restricting admission at the provider with an organization condition and, when needed, a branch condition such as assertion.repository_owner=='ORG' && assertion.ref=='refs/heads/main'.[1][2][6]

  • Finally, allow the principal from the provider to use a service principal:[1][2][6]
gitHubRepoName="repo-org/repo-name"
gcloud iam service-accounts add-iam-policy-binding $saId \
  --role "roles/iam.workloadIdentityUser" \
  --member "principalSet://iam.googleapis.com/${poolId}/attribute.${attributeMappingScope}/${gitHubRepoName}"

[!WARNING] Note how in the previous member we are specifying the org-name/repo-name as conditions to be able to access the service account (other params that makes it more restrictive like the branch could also be used).[1][2]

However it's also possible to allow all github to access the service account creating a provider such the following using a wildcard:[2][3]

# Create a Workload Identity Pool
poolName=wi-pool2

gcloud iam workload-identity-pools create $poolName \
  --location global \
  --display-name $poolName

poolId=$(gcloud iam workload-identity-pools describe $poolName \
  --location global \
  --format='get(name)')

gcloud iam workload-identity-pools providers create-oidc "$poolName" \
  --project="$projectId" \
  --location="global" \
  --workload-identity-pool="$poolName" \
  --display-name="CTF provider" \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,\
attribute.actor=assertion.actor,\
attribute.repository=assertion.repository,\
attribute.aud=assertion.aud" \
  --attribute-condition="assertion.repository_owner!=''"

providerId=$(gcloud iam workload-identity-pools providers describe $poolName \
  --location global \
  --workload-identity-pool $poolName \
  --format='get(name)')

# CHECK THE WILDCARD
gcloud iam service-accounts add-iam-policy-binding "${saId}" \
  --project="${projectId}" \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/${poolId}/*"

The wildcard principal set represents every identity in the workload identity pool, so any GitHub identity admitted by this provider can attempt to impersonate the service account.[2][3]

[!WARNING] In this case anyone could access the service account from github actions, so it's important always to check how the member is defined.
It should be always something like this:

attribute.{custom_attribute}:principalSet://iam.googleapis.com/projects/{project}/locations/{location}/workloadIdentityPools/{pool}/attribute.{custom_attribute}/{value}[2][3]

Github

Remember to change ${providerId} and ${saId} for their respective values.[3][4][6]

name: Check GCP action
on:
  workflow_dispatch:
  pull_request:
    branches:
      - main

permissions:
  id-token: write

jobs:
  Get_OIDC_ID_token:
    runs-on: ubuntu-latest
    steps:
      - uses: "actions/checkout@v4"
      - id: "auth"
        name: "Authenticate to GCP"
        uses: "google-github-actions/auth@v2.1.3"
        with:
          create_credentials_file: "true"
          workload_identity_provider: "${providerId}" # In the providerId, the numerical project ID (12 digit number) should be used instead of the alphanumeric project ID. ex: projects/123123123123/locations/global/workloadIdentityPools/iam-lab-7-gh-pool/providers/iam-lab-7-gh-pool-oidc-provider'
          service_account: "${saId}" # <sa-name>@<proj-id>.iam.gserviceaccount.com
      - name: "Set up Cloud SDK"
        uses: "google-github-actions/setup-gcloud@v3"
      - id: "gcloud"
        name: "gcloud"
        run: |-
          gcloud config set project <project-id>
          gcloud auth list
          gcloud projects list
          gcloud secrets list

The workflow checks out the repository before creating the credentials file, uses only supported auth inputs, and configures gcloud through the current setup-gcloud action.[6][7][10]

References

[!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Browse the full HackTricks Training catalog.

Support HackTricks
Sponsored