Google Cloud Provider — Credentials and Permissions

First PublishedFeb 16, 2026ByAtif Alam

When you use the Google Cloud provider (google or google-beta) in Terraform, Terraform calls the Google Cloud APIs to create, update, and delete resources. Those API calls are authorized using GCP credentials.

Terraform does not have its own credential system — the Google provider uses Application Default Credentials (ADC), the same mechanism used by the Google Cloud client libraries and the gcloud CLI.

Whoever or whatever runs terraform plan and terraform apply must have a Google Cloud identity (user or service account) with the right IAM permissions on the project (and optionally folder/org) you manage.

How Terraform Gets Google Cloud Credentials

The Google provider resolves credentials via Application Default Credentials, in this order:

Source	When it’s used
Environment variable	GOOGLE_APPLICATION_CREDENTIALS — path to a service account key JSON file. Common in CI.
JSON in env	GOOGLE_CREDENTIALS — the raw JSON content of a service account key (e.g. from a CI secret).
User credentials	After you run gcloud auth application-default login, credentials are stored under ~/.config/gcloud/. The provider uses these for local development.
Attached service account	When Terraform runs on Google Cloud (Compute Engine VM, Cloud Run, GKE, etc.) with a service account attached, ADC uses that identity. No key file needed.
Workload Identity	In CI (e.g. GitHub Actions with Workload Identity Federation), the pipeline can obtain a short-lived token and the provider uses it — no key file to store.

Example: configuring the provider with project and region:

provider "google" {
  project = "my-gcp-project-id"
  region  = "us-central1"
}

You can set credentials in the provider block to a path or the JSON string, but often you leave it unset and rely on GOOGLE_APPLICATION_CREDENTIALS or gcloud auth application-default login so the same config works locally and in CI by changing only the environment.

IAM Permissions Terraform Needs

Terraform can only create or change resources for which the active credentials have IAM permissions. The identity (user or service account) must have roles that allow the API operations your resources use. For example:

• google_compute_instance → compute.instances.create, compute.disks.create, etc.
• google_storage_bucket → storage.buckets.create, storage.buckets.update, etc.
• google_project_iam_member → resourcemanager.projects.getIamPolicy, setIamPolicy, etc.
• google_service_account → iam.serviceAccounts.create, iam.serviceAccountKeys.create, etc.

There is no single “Terraform” role that covers every resource. In practice you either:

• Grant broad roles (e.g. Editor or Owner on a project) for simplicity, or
• Use custom roles or multiple narrow predefined roles (e.g. Compute Admin, Storage Admin) scoped to the project so Terraform has least privilege.

Best practice: use a dedicated service account for Terraform (e.g. terraform@my-project.iam.gserviceaccount.com) with only the roles your config needs, and avoid long-lived key files when you can use Workload Identity Federation in CI or an attached service account when Terraform runs on GCP.

Running Terraform in CI (GitHub Actions, etc.)

In CI, do not commit service account key JSON. Prefer:

• Workload Identity Federation — Link your CI provider (e.g. GitHub) to GCP so the pipeline gets short-lived tokens. No key file; set GOOGLE_APPLICATION_CREDENTIALS to the generated credentials file in the job, or use the OIDC-based flow.
• Service account key — If federation isn’t an option, store the key JSON in CI secrets and set GOOGLE_CREDENTIALS (or write to a file and set GOOGLE_APPLICATION_CREDENTIALS) in the job environment.

The provider block stays the same; only the source of the credentials changes. For more on CI/CD layout and storing secrets, see Best Practices.

Summary

• Terraform’s permissions with Google Cloud come from Application Default Credentials — key file (env), gcloud auth application-default login, or an attached service account.
• The identity (user or service account) must have IAM roles that allow the API operations your resources need; there is no single “Terraform” role.
• Use a dedicated service account for Terraform and least privilege; in CI, prefer Workload Identity Federation over long-lived key files.