auth icon indicating copy to clipboard operation
auth copied to clipboard

Token lifetime for longer running jobs when using Direct Workload Identity Federation

Open lopter opened this issue 5 months ago • 9 comments

Hello,

I am trying to setup some CI jobs that will run Terraform commands with Terraform configured to use a Google Cloud Storage bucket (docs) to store its state and do its locking.

Due to the nature of Terraform operations, a 10 (or 5[^1]) minutes TTL for the authentication token feels short. I don't see how this TTL can be raised. What's my next best option?

Documents I have been through:

  • README.md;
  • SECURITY_CONSIDERATIONS.md;
  • EXAMPLES.md:
    • In particular "Generating an OAuth 2.0 Access Token" which mentions a lifetime of up to 12 hours, but my understanding from #432 (see below) is that this gets cut back to 5 minutes on GitHub.
  • https://cloud.google.com/iam/docs/manage-workload-identity-pools-providers;
  • https://cloud.google.com/storage/docs/access-control/iam-reference;
  • Previous issues:
    • #474;
    • #432[^2];

[^1]: This is still unclear to me tbh: if I understand correctly it's 5 minutes when using Workload Identity Federation through a Service Account and 10 minutes when using Direct Workload Identity Federation. [^2]: This comment in particular.

lopter avatar Aug 13 '25 19:08 lopter

Hi there @lopter :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.

github-actions[bot] avatar Aug 13 '25 19:08 github-actions[bot]

The idea I am entertaining right now would be to use WIF to get an OAuth 2 token for GCP KMS, then use that to get some service account key for our storage bucket out of Sops, and then have some other job somewhere to rotate the service account key in Sops on a regular basis…

lopter avatar Aug 13 '25 19:08 lopter

You can get an oauth token that is longer than the OIDC token.

sethvargo avatar Aug 13 '25 20:08 sethvargo

Oh! I thought that wasn't possible according to https://github.com/google-github-actions/auth/issues/474#issuecomment-2830075236

lopter avatar Aug 13 '25 21:08 lopter

I'm pretty sure you can get an oauth token that is longer than the OIDC token, but you cannot get a Google OIDC token that is longer than GitHub's OIDC token, but I have not checked it recently.

sethvargo avatar Aug 13 '25 21:08 sethvargo

Alright thank you, to sum it up, the inputs I need to provide are the ones documented in Generating OAuth 2.0 access tokens:

  1. Create a service account named e.g. "github-terraform";
  2. Setup IAM so that the new service account can read/write to the GCS bucket of interest;
  3. Set inputs with:
    1. service_account: see step 1;
    2. token_format: access_token;
    3. access_token_lifetime: default of 1 hour is reasonable;
    4. Use the following list for access_token_scopes (I used this as a reference):
      • https://www.googleapis.com/auth/cloud-platform.read-only;
      • https://www.googleapis.com/auth/devstorage.read_write;
    5. create_credentials_file: true;
    6. export_environment_variables: true.

To be sure, those steps do not correspond to any of the setup sections, but that's ok?

And, in the future if I want to manage Google Cloud resources with Terraform (and not just use GCS to store the Terraform state), then I can edit the IAM config of the service account and access_token_scopes accordingly.

lopter avatar Aug 13 '25 23:08 lopter

You probably want the "cloud-platform" scope and use Cloud IAM permissions instead of oauth scopes.

sethvargo avatar Aug 14 '25 01:08 sethvargo

Does that mean that step 3.4 can just use the default value of https://www.googleapis.com/auth/cloud-platform? And that this value actually means that access_token_scopes is actually controlled/delegated to the IAM roles granted on the service account from step 1?

lopter avatar Aug 14 '25 01:08 lopter

Correct

sethvargo avatar Aug 14 '25 16:08 sethvargo