Local testing
lpezet opened this issue · comments
TL;DR
Supporting local testing, like using Nektos' act
to test workflows locally.
Disclaimer: 1) In the WIF case, I don't fully comprehend how ACTIONS_ID_TOKEN_REQUEST_TOKEN is generated by Github. And maybe there's an easy way to work with it (generate one? that would sound like a security flaw...no?), and 2) I also do not understand the other possible setups with google-github-actions/auth
.
Detailed design
When using Workload Identity Federation, the usual setup is something like:
steps:
- uses: actions/checkout@v3
- id: 'auth'
uses: 'google-github-actions/auth@v2'
with:
create_credentials_file: true # optional
token_format: 'access_token'
workload_identity_provider: ${{ secrets.WORKLOAD_ID_PROVIDER_NAME }}
service_account: ${{ secrets.WORKLOAD_ID_SA_EMAIL }}
Now the problem then comes when testing such workflow locally.
Considering the following:
- Everything is setup correctly in Github (i.e. WIF works just fine). This is irrelevant here but just want to make sure we're not focusing on fixing something that doesn't need fixing.
- A simple workflow, such as:
name: Test Me Locally
on:
push:
pull_request:
jobs:
simple-job:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- id: 'auth'
uses: 'google-github-actions/auth@v2'
with:
create_credentials_file: true
token_format: 'access_token'
workload_identity_provider: ${{ secrets.WORKLOAD_ID_PROVIDER_NAME }}
service_account: ${{ secrets.WORKLOAD_ID_SA_EMAIL }}
- name: Simple gcloud action
run: |
gcloud storage ls gs://my-bucket --project=my-project
- When testing locally, I'd like to avoid having to change (manually or not) the content of that workflow. The goal is really to reduce the amount of changes between a local environment and Github, to make the tests as meaningful as possible. If
X
is the configuration needed on Github for a workflow to pass, testingX-n
configuration, wheren
is as small as possible, it still meaningful. I can focus on then
changes if my workflow is still not working. In layman terms, don't ask me to switch from WIF to service account keys for the sake of testing. - A clear (?) understanding that
google-github-actions/auth
's goal is to provide an environment where credentials are available for tools likegcloud
to function.
It would be very useful to test my workflow as such:
act --env GOOGLE_SOME_CREDS_MAYBE_ACCESS_TOKEN=some_value push
Additional information
In this specific situation, the problem lies with https://github.com/google-github-actions/auth/blob/main/src/main.ts#L108, where ACTIONS_ID_TOKEN_REQUEST_TOKEN
and ACTIONS_ID_TOKEN_REQUEST_URL
are not provided (the URL one could easily be provided though).
One solution could be to tweak the if()
logic at https://github.com/google-github-actions/auth/blob/main/src/main.ts#L100.
Change the existing logic:
# https://github.com/google-github-actions/auth/blob/main/src/main.ts#L100
if (workloadIdentityProvider) {
...deal with oidc token...
client = new WorkloadIdentityFederationClient({ ... })
else {
..do with credentials JSON...
client = new ServiceAccountKeyClient({ ... })
}
to something like this:
const env_creds = process.env.GOOGLE_SOMETHING
...
if (env_creds) { // must be first to "override" the WIF
...deal with creds provided as environment variable...
client = new ?????({ ... })
} else if (workloadIdentityProvider) {
...deal with oidc token...
client = new WorkloadIdentityFederationClient({ ... })
else {
..do with credentials JSON...
client = new ServiceAccountKeyClient({ ... })
}
Security-wise, it's not worse than service keys (it's actually an impractical middle ground between WIF and service account keys, if someone really really wanted to use this beyond local testing, in Github that is).
Hi there @lpezet 👋!
Thank you for opening an issue. Our team will triage this as soon as we can. Please take a moment to review the troubleshooting steps which lists common error messages and their resolution steps.
Hi @lpezet - thank you for opening an issue. act
is not officially supported by GitHub, and I'm opposed to adding specific logic for ecosystem tooling. OIDC is not specific to Google Cloud (AWS, Azure, and other IDPs support federated identity), so it would be better to raise this issue to act
and have the act
runtime serve the OIDC URLs and tokens.
In your case, you could probably inject CLOUDSDK_AUTH_ACCESS_TOKEN
and add an if
conditional in your workflow to skip the auth action if that envvar is defined.
It's not really about act
. I used it only as an example.
My actual case is actually when using Terraform and Google Provider.
I'll skip google-github-actions/auth
as you mentioned, and figure out a different way then.
Thanks.