The Google Cloud Provider

The google provider lets Terraform manage Google Cloud Platform resources — from GCS buckets and Compute Engine instances to GKE clusters and BigQuery datasets. Unlike some clouds, GCP work always revolves around a project, and most resources also need a default region and zone. This page covers declaring the provider, the three common ways it authenticates, and a worked example that provisions real infrastructure. Everything here works identically under Terraform 1.5+ and OpenTofu.

Declaring the provider

Pin the provider in a required_providers block so builds are reproducible across machines and CI. The provider is published under the official hashicorp/google namespace. GCP also offers a google-beta provider for preview features; the two are configured the same way and are frequently used side by side via aliases.

terraform {
  required_version = ">= 1.5"

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 6.0"
    }
  }
}

provider "google" {
  project = "my-app-prod-4821"
  region  = "us-central1"
  zone    = "us-central1-a"
}

The ~> 6.0 constraint allows minor and patch upgrades (6.1, 6.2, …) but blocks the breaking 7.x major version. Run terraform init to download the plugin and record the resolved version in .terraform.lock.hcl.

Configuration options

The provider "google" block accepts many arguments. The ones you will reach for most are below.

Argument	Purpose
`project`	Default GCP project ID for all resources. Required (or via `GOOGLE_PROJECT`).
`region`	Default region, e.g. `europe-west1`. Used by regional resources.
`zone`	Default zone, e.g. `europe-west1-b`. Used by zonal resources like VMs.
`credentials`	Path to (or contents of) a service account key JSON file.
`impersonate_service_account`	Email of a service account to impersonate.
`user_project_override`	Bill quota/API usage to the resource’s project.

Authentication

Terraform resolves Google credentials in a defined order; the first method it finds wins.

Application Default Credentials (recommended)

For local development the cleanest approach is Application Default Credentials (ADC). You authenticate once with the gcloud CLI, and Terraform automatically picks up the resulting credentials — no keys in your configuration or environment.

gcloud auth application-default login
gcloud config set project my-app-prod-4821

Output:

Credentials saved to file:
[/home/dev/.config/gcloud/application_default_credentials.json]

These credentials will be used by any library that requests
Application Default Credentials (ADC).

With ADC in place, the provider block needs nothing but project, region, and zone.

Service account key

In CI or on a machine where interactive login is impossible, point the provider at a service account key. Prefer supplying it through the environment rather than committing a path into HCL.

export GOOGLE_CREDENTIALS="$(cat terraform-deployer-key.json)"
export GOOGLE_PROJECT="my-app-prod-4821"

If you must reference it in HCL, read the file rather than pasting the JSON inline:

provider "google" {
  project     = "my-app-prod-4821"
  region      = "us-central1"
  credentials = file("terraform-deployer-key.json")
}

Warning: Never commit a service account key file to version control. Add *-key.json to .gitignore, and prefer Workload Identity Federation or service account impersonation over long-lived keys wherever possible.

Service account impersonation

A keyless alternative: authenticate as yourself (or as a Workload Identity in CI), then impersonate a deployer service account. This keeps the powerful permissions on the service account while leaving no key material on disk.

provider "google" {
  project                     = "my-app-prod-4821"
  region                      = "us-central1"
  impersonate_service_account = "[email protected]"
}

Worked example: a GCS bucket and a VM

This configuration creates a versioned Cloud Storage bucket and a small Compute Engine instance, then exports useful attributes. It assumes you have authenticated via ADC.

resource "google_storage_bucket" "assets" {
  name                        = "my-app-prod-assets-4821"
  location                    = "US"
  force_destroy               = false
  uniform_bucket_level_access = true

  versioning {
    enabled = true
  }

  lifecycle_rule {
    condition {
      age = 90
    }
    action {
      type = "Delete"
    }
  }
}

resource "google_compute_instance" "web" {
  name         = "web-1"
  machine_type = "e2-small"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
      size  = 20
    }
  }

  network_interface {
    network = "default"
    access_config {} # ephemeral public IP
  }

  labels = {
    environment = "prod"
    managed_by  = "terraform"
  }
}

output "bucket_url" {
  value = google_storage_bucket.assets.url
}

output "instance_ip" {
  value = google_compute_instance.web.network_interface[0].access_config[0].nat_ip
}

Running terraform apply provisions both resources: