Add support for access tokens

[awolde]

TL;DR

Would be nice if we can use access tokens instead of json keys. Have something like:

        with:
          access_token: ${{ secrets.GCP_ACCESS_TOKEN }}

That way, we can use short lived tokens from gcloud auth print-access-token to setup pipelines, and not generating json keys or go to the extent of setting up workload identity.

Detailed design

No response

Additional information

No response

[github-actions[bot]]

Hi there @awolde :wave:!

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.

[sethvargo]

Hi @awolde

I'm not sure what you're asking for. If you already have gcloud and gcloud is authenticated, then you shouldn't need the "auth" function. Most of the ecosystem will detect and use Application Default Credentials when gcloud is installed.

If you have a specific tool that expects an access token, you usually need to provide it to that tool via an envvar or similar configurable (e.g. Terraform access_token or gcloud's envvar).

[awolde]

@sethvargo

Ok I guess to be more clear, there are many ways you can authenticate to GCP. The most famous one is using service account json keys which is not desirable. You can also use access tokens to perform any gcloud command, for example:

gcloud compute instances list --access-token-file token_file

This token_file is coming from a gcloud auth print-access-token output saved in a file. Just like you create a service account and download its keys, you can get your access token (user account) from an already authenticated gcloud environment. The same access token can be used in terraform for example if you export it as GOOGLE_OATH_ACCESS_TOKEN env var. These tokens are short-lived and they expire after an hr, which makes them ideal for testing. So I put this token into a GitHub Actions secrets and should be able to use it in your container.

[awolde]

Correction: GOOGLE_OAUTH_ACCESS_TOKEN

[sethvargo]

Hi @awolde, I understand that, but I don't understand what you're asking for. As you noted (emphasis mine),

Just like you create a service account and download its keys, you can get your access token (user account) from an already authenticated gcloud environment.

This requires gcloud be authenticated via the OAuth 2.0 user flow, which requires interaction via a browser. If you're running GitHub Actions in an environment where gcloud is already authenticated, then you don't need to generate an access token at all; the community tooling and client libraries will find those credentials as part of ADC.

Are you saying that you generate an access token on your local machine and then upload it to GitHub Actions? I think you may be confusing machine-to-machine authentication with user-to-machine authentication.

[awolde]

@sethvargo The last paragraph is what I am doing - generate a token and use that in Github actions. I can auth using a service account (impersonation or directly with json file) and print its access token too, doesn't have to be a GCP user account. I just don't want to use static json keys. Generally what I am asking is support for what gcloud takes as a "legal" way to authenticate with GCP, whether that is user-machine or machine-machine auth.

[sethvargo]

Hi @awolde - that's not a workflow we're going to support here, since there's nothing we can do. Every downstream tool would need to support authentication via an OAuth 2.0 token from an environment variable, etc. We're focused on fully-automated use cases. The entire ecosystem would need to support that, and, if it did, you could just export an environment variable and bypass the auth action entirely.

If you don't want to use JSON Service Account Keys, you can use Workload Identity Federation, which eliminates the need for long-lived credentials.