Getting Started with the Google Cloud Terraform Provider

The Google Cloud provider in brief

The Terraform provider for Google Cloud Platform lets you define, configure, and deploy resources in a GCP account. Like every Terraform provider, the GCP provider gives engineers a common interface to the GCP API. Because the interface is shared, you can work across several clouds without learning a separate, provider-specific configuration language for each one (AWS CloudFormation, Azure Bicep, and so on).

The Google provider is a little different in that it ships in two versions:

• google: the generally available version
• google-beta: the beta version

Having two variants lets engineers and organisations try upcoming GCP features early and get ready for a change before it lands in the GA provider.

Configuration

I've split configuration into two parts: authentication and general configuration.

Authentication

Like most providers on the Terraform Registry, this one can be configured and authenticated in several ways. By default, the provider tries to authenticate with GCP using User Application Default Credentials (ADCs) via the gcloud CLI utility.

The provider exposes the credentials argument so you can point it at a service account key file. This file must be in JSON format. You can also use environment variables, listed here in order of precedence:

• GOOGLE_CREDENTIALS
• GOOGLE_CLOUD_KEYFILE_JSON
• GOOGLE_KEYFILE_JSON

Authentication is automatically available when running Terraform commands if:

• they are being run on a GCE instance
• or on a workstation where the gcloud auth application-default login command has been executed.

These are the simplest ways to authenticate with GCP.

On top of those credential-based approaches, you can also authenticate with an OAuth 2.0 access token. You set this token with the access_token property or the GOOGLE_OAUTH_ACCESS_TOKEN environment variable. You can learn more about generating an access token here.

General Configuration

The provider lets you set values like:

• project
• region
• zone
• default_labels

These aren't all the options, but they're the most useful.

Setting the project at the provider level means engineers don't need to set the project on each resource. You can still override the project at a resource level. Both region and zone let you set the defaults for where resources (e.g., virtual machines) get provisioned. The most useful option, in my opinion, is default_labels, which applies a set of default labels to every resource this instance of the provider creates. In other providers, that's not so easy to do.

Examples

For both examples, assume that the gcloud auth application-default login command has been run.

Here's the provider in its most basic form:

provider "google" {
  project = "example"
  region  = "australia-southeast2"
  zone    = "australia-southeast2-b"
}

This sets the project, region, and zone properties, so we don't have to configure them on each resource.

The next example runs an instance of both the GA and Beta providers. This lets you configure resources differently, or use different resources entirely.

provider "google" {
  project = "example"
  region  = "australia-southeast2"
  zone    = "australia-southeast2-b"
}
 
provider "google-beta" {
  project = "example"
  region  = "australia-southeast2"
  zone    = "australia-southeast2-b"
}
 
resource "google_container_cluster" "ga" {
  provider = google
 
  name = "ga-cluster"
 
  initial_node_count = 1
 
  timeouts {
    create = "30m"
    update = "40m"
  }
}
 
resource "google_container_cluster" "beta" {
  provider = google-beta
 
  name = "beta-cluster"
 
  initial_node_count = 1
 
  timeouts {
    create = "30m"
    update = "40m"
  }
}

This code has two instances of google_container_cluster. The first uses the GA version of the GCP provider (google). The second uses the Beta version of the GCP provider (google-beta). The example doesn't show any configuration differences between GA and Beta for this resource type, but if there were any, this is how you'd handle them.

Where to go next

For authentication, the main mechanisms are ADCs and temporary OAuth access tokens. I generally recommend ADCs configured automatically via GCE instance identity. For general configuration, set project, region, zone, and default_labels at the provider level so every resource the Terraform Google provider creates starts from sensible defaults. For all the details on the provider configuration, read through the Google Provider Configuration Reference.