Closed apex-omontgomery closed 2 years ago
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.
Thank you for the prompt response, and your recommendation of deleting the credentials is perfectly reasonable.
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
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.
If possible please expose a similar option.
Additional information
No response