Terraform Version

Should not be relevant, but here :

$ terraform --version
Terraform v1.0.9
on linux_amd64

The provider is v1.14.0

Affected Resource(s)

This issue affects the provider configuration itself, when connecting to GCP.
You may therefore consider it affects all resources.

Terraform Configuration Files

provider "postgresql" {
  scheme    = "gcppostgres"
  host      = "aaaaa:bbbbb:ccccc"
  username  = "user"
  port      = 5432
  password  = "password123"
  superuser = false
}

The values above are placeholders, but should not matter here.

Debug Output

N/A

Panic Output

N/A

Desired Behavior

I'd like a config option to provide the service account credentials directly to the provider, for example something like :

provider "postgresql" {
  scheme    = "gcppostgres"
  host      = "aaaaa:bbbbb:ccccc"
  username  = "user"
  port      = 5432
  password  = "password123"
  superuser = false

  gcp_credentials = "/some/path/to/key.json"
}

Actual Behavior

As per the docs, such an option does not exist.

Steps to Reproduce

N/A

References

N/A

Important Factoids

Both the terraform GCP state backend and the terraform GCP provider support 2 ways to provide service account credentials :

• explicit configuration in the provider block
• automatic credential detection by the GCP SDK, including :
  • GOOGLE_APPLICATION_CREDENTIALS envvar
  • creds configured with gcloud auth application-default
  • Default creds configured by GCP (for example, when running on a GCP VM...)

This means that using this provider together with the official GCP provider/backend creates an API inconsistency regarding authentication, which has several implications :

• When using multiple service accounts across multiple configurations, users need to manually reimplement logic to pass the correct service account when invoking terraform. With the GCP provider, it would be possible to manage this case only with terraform provider configuration
• It's not possible to use the provider with a service account created by terraform in the same run. It would be with such an API.

If such an option is implemented, I'd suggest making sure it does have the same behavior as the official provider. In particular, credentials field in the official provider can either be configured with a string containing a json key, or a path to a file containing such a key.

I assume the Gocloud library accepts such a parameter, and that the logic to implement in this provider would be minimal. Mostly, accepting an extra optional argument, then, if present, validating its structure and passing it to gocloud.
I tried looking into gocloud to see if this was possible, but I'm no go dev, and got lost pretty fast.