Allow ability to create workload identity token in alternative path

[apex-omontgomery]

TL;DR

There appears to be no way to create the token in a specific location, which makes the workflow identity something you should not use when using github actions to create PRs.

https://github.com/google-github-actions/auth/blob/main/src/main.ts#L136

Detailed design

name: "Generate Metadata"

on:
  workflow_dispatch: {}

jobs:
  generate-metadata
    name: Generate Metadata
    runs-on: ubuntu-20.04

    permissions:
      contents: 'read'
      id-token: 'write'

    steps:
      - name: Check out repository code
        uses: actions/checkout@v2
        with:
          ref: main # restrict this run to only main branch, workflow_dispatch does not support limiting to a branch

      - name: 'auth'
        uses: 'google-github-actions/auth@v0'
        with:
          workload_identity_provider: 'projects/<projectNumber>/locations/global/workloadIdentityPools/<poolname>/providers/<providerName>'
          service_account: '<serviceAccount>@<projectID>.iam.gserviceaccount.com'

      # further step to modify contents in repo

      # another step to generate token to create PR

      # another step to create PR

In that last step, a PR will be created with the expected changes, but the token will be included in the PR.

In another google module, an argument is exposed to specify a different path that allows a consumer to specify where the key should be placed.

      - name: Setup Google Cloud SDK
        uses: google-github-actions/setup-gcloud@master
        with:
          service_account_key: ${{ secrets.GCP_CREDENTIALS }}
          export_default_credentials: true
          credentials_file_path: /tmp/gcp-credentials.json

If possible please expose a similar option.

Additional information

No response

[sethvargo]

Hi @wimo7083

There is no "token" that is stored with Workload Identity Federation. There's a credentials file, but that name might be misleading, since it doesn't actually include any credentials. It includes information about how to get credentials:

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/469401941463/locations/global/workloadIdentityPools/github-actions/providers/sethvargo",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "credential_source": {
    "url": "https://foo.bar/",
    "headers": {
      "Authorization": "Bearer only_possible_secret"
    },
    "format": {
      "type": "json",
      "subject_token_field_name": "value"
    }
  },
  "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/gh-actions-testing@actions-oidc-test.iam.gserviceaccount.com:generateAccessToken"
}

The only possible secret that exists in that file is the temporary token with GitHub injects as an environment variable. Since that value is also exposed via an environment variable (and since the token itself can only authenticate to the GitHub endpoint), there's no change in threat model to have it in the credentials file.

The token itself is also removed from the workspace on each job completion. If you need to delete the file earlier (such as to create a PR), you can manually delete it using the credentials_file_path output:

- run: rm ${{steps.auth.outputs.credentials_file_path}}

I'm not in favor of allowing users to customize the place where the credential is stored, especially since self-hosted runners are not ephemeral by default. The current method ensures we have permission to write the file and permissions to clean up the file when finished. If you need to remove the file before the job completes, you can remove it manually as shown above. Please let me know if you have additional questions.

[apex-omontgomery]

Thank you for the prompt response, and your recommendation of deleting the credentials is perfectly reasonable.