What is your suggestion?

Our example Terraform templates for Google and AWS are designed so that cloud provider credentials are passed in via parameters. In contrast, the standard practice for Terraform is that the execution environment itself is authenticated with the cloud and Terraform grabs the credentials it needs from well-known locations (environment variables, files in the user directory).

We should re-align our Terraform examples and documents to follow this pattern.

In Coder v2 parlance, the terraform provisioner needs to be executed in an authenticated environment. Since we run provisionerd/provisioners in-process with coderd today, this amounts running coderd in an authenticated environment.

E.g., users need to run gcloud auth login before they run coder server if they are executing locally. If they run coder in a cloud VM for managing infra in the same cloud, they don't have to do anything when starting coderd and it will use the VM's service account.

Why do you want this feature?

Our current implementation results in authorization credentials for cloud infra being stored in the coder database, which means it is a high value target for attackers. It's better for us to know less and encourage end users to manage credentials in a way that doesn't introduce coder as an attack point. In particular, if you run the provisioner on a cloud-managed VM, Terraform can natively authenticate with that cloud.

Secondly, some users are getting surprised they are being prompted for service account credentials when they are running coder server after already having authenticated. Most other software that interacts with the cloud doesn't prompt and just uses local credentials if they exist.

Are there any workarounds to get this functionality today?

Write your own template

Are you interested in submitting a PR for this?

Yes

cc @kylecarbs