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

[lopter]

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¹) 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 Document token lifetimes #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:
  • Default auth_token expiration is 5 minutes instead of 10 minutes #474;
  • Document token lifetimes #432²;

Footnotes

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. ↩

[github-actions]

Hi there @lopter 👋!

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.

[lopter]

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…

[sethvargo]

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

[lopter]

Oh! I thought that wasn't possible according to #474 (comment)

[sethvargo]

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.

[lopter]

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.

[sethvargo]

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

[lopter]

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?

[sethvargo]

Correct