You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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, testing X-n configuration, where n is as small as possible, it still meaningful. I can focus on the n 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 like gcloud to function.
It would be very useful to test my workflow as such:
# 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).
The text was updated successfully, but these errors were encountered:
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.
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:
Now the problem then comes when testing such workflow locally.
Considering the following:
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.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:
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
andACTIONS_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:
to something like this:
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).
The text was updated successfully, but these errors were encountered: