Terrafrom cli plan and GCP workflow identity federation

Terraform HCP Terraform
1

Hi,

we setup Dynamic Provider Credentials and GCP Workflow Identity Federation in Terraform Cloud. This works perfectly fine for terrform runs triggered from the Terraform Cloud UI (manually or automatically), google provider authenticates and impersonates service account no problem.

However when we trigger a remote plan run from CLI (terraform plan) the google provider fails because it cannot find credentials. Are we doing something wrong here or are the dynamic provider credentials not supported from remote plans? The full error is show below:

Preparing the remote plan…

To view this run in a browser, visit:
https://app.terraform.io/app/REDACTED

Waiting for the plan to start…

Terraform v1.5.2
on linux_amd64
Initializing plugins and modules…
╷
│ Error: Attempted to load application default credentials since neither credentials nor access_token was set in the provider block. No credentials loaded. To use your gcloud credentials, run ‘gcloud auth application-default login’
│
│ with provider[“Terraform Registry”],
│ on line 0:
│ (source code not available)
│
│ google: could not find default credentials. See
│ Set up Application Default Credentials  |  Authentication  |  Google Cloud for more
│ information
╵
╷
│ Error: Invalid provider configuration
│
│ Provider “Terraform Registry” requires explicit
│ configuration. Add a provider block to the root module and configure the
│ provider’s required arguments as described in the provider documentation.
│

2

Hi @karol.piwowarski!

This seems like something that would be easier to solve with the ability to see how you’ve configured your workspace and your trust policy in Google Cloud Platform.

Because of that, I would suggest sending this question to HashiCorp Support instead, both because they can (with your permission) directly inspect your workspace settings and because the customer support channel is private and therefore it’d be safer to share information about your trust policy there so you can avoid accidentally publicly sharing something that might be useful to an attacker.

3

Hi ,

The problematic workspace was the first one I created. All subsequent workspaces I created worked perfectly fine. I can’t figure what I did wrong with the first one. In any case it was test workspace and I set up 10 more since and did not encounter this issue.

it’s all good now