Google Provider Configuration Reference

The google and google-beta provider blocks are used to configure the credentials you use to authenticate with GCP, as well as a default project and location (zone and/or region) for your resources. The same values are available between the provider versions, but must be configured in separate provider blocks.

Example Usage - Basic provider blocks

provider "google" {
  project     = "my-project-id"
  region      = "us-central1"
  zone        = "us-central1-c"
}
provider "google-beta" {
  project     = "my-project-id"
  region      = "us-central1"
  zone        = "us-central1-c"
}

Example Usage - Using beta features with google-beta

To use Google Cloud Platform features that are in beta, you need to both:

See Provider Versions for a full reference on how to use features from different GCP API versions in the Google provider.

resource "google_compute_instance" "ga-instance" {
  provider = google

  # ...
}

resource "google_compute_instance" "beta-instance" {
  provider = google-beta

  # ...
}

provider "google-beta" {}

Authentication

Running Terraform on your workstation.

If you are using Terraform on your workstation we recommend that you install gcloud and authenticate using User Application Default Credentials ("ADCs") as a primary authentication method. You can enable ADCs by running the command gcloud auth application-default login.

Google Cloud reads the quota project for requests will be read automatically from the core/project value. You can override this project by specifying the --project flag when running gcloud auth application-default login. gcloud should return this message if you have set the correct billing project: Quota project "your-project" was added to ADC which can be used by Google client libraries for billing and quota.

Running Terraform on Google Cloud

If you are running Terraform in a machine on Google Cloud, you can configure that instance or cluster to use a Google Service Account. This allows Terraform to authenticate to Google Cloud without a separate credential/authentication file. Ensure that the scope of the VM/Cluster is set to or includes https://www.googleapis.com/auth/cloud-platform.

Running Terraform Outside of Google Cloud

If you are running Terraform outside of Google Cloud, generate an external credential configuration file (example for OIDC based federation) or a service account key file and set the GOOGLE_APPLICATION_CREDENTIALS environment variable to the path of the JSON file. Terraform will use that file for authentication. Terraform supports the full range of authentication options documented for Google Cloud.

Using Terraform Cloud

Place your credentials in a Terraform Cloud environment variable:

  1. Create an environment variable called GOOGLE_CREDENTIALS in your Terraform Cloud workspace.
  2. Remove the newline characters from your JSON key file and then paste the credentials into the environment variable value field. You can use the tr command to strip newline characters. cat key.json | tr -s '\n' ' '
  3. Mark the variable as Sensitive and click Save variable.

All runs within the workspace will use the GOOGLE_CREDENTIALS variable to authenticate with Google Cloud Platform.

Impersonating Service Accounts

Terraform can impersonate a Google service account, acting as a service account without managing its key locally.

To impersonate a service account, you must use another authentication method to act as a primary identity, and the primary identity must have the roles/iam.serviceAccountTokenCreator role on the service account Terraform is impersonating. Google Cloud Platform checks permissions and quotas against the impersonated service account regardless of the primary identity in use.

Authentication Configuration


By default, the following scopes are configured:

* https://www.googleapis.com/auth/cloud-platform
* https://www.googleapis.com/auth/userinfo.email


Quota Management Configuration

Service account credentials are associated with the project the service account was created in. Credentials that come from the gcloud tool are associated with a project owned by Google. In order to properly use credentials that come from gcloud with Terraform, it is recommended to set this property to true.

user_project_override uses the X-Goog-User-Project system parameter. When set to true, the caller must have serviceusage.services.use permission on the quota project.


Provider Default Values Configuration




provider "google" {
  default_labels = {
    my_global_key = "one"
    my_default_key = "two"
  }
}

resource "google_compute_address" "my_address" {
  name     = "my-address"

  labels = {
    my_key = "three"
    # overrides provider-wide setting
    my_default_key = "four"
  }
}

The default value is false. No label will be added unless the provider is explicitly configured to do so by setting the value to true.


If add_terraform_attribution_label is false, this configuration is ignored. This example configuration adds the label to resources every time terraform apply is run:

provider "google" {
  add_terraform_attribution_label               = true
  terraform_attribution_label_addition_strategy = "PROACTIVE"
}

Advanced Settings Configuration



provider "google" {
  alias                   = "compute_beta_endpoint"
  compute_custom_endpoint = "https://www.googleapis.com/compute/beta/"
}

Custom endpoints are an advanced feature. To determine the possible values you can set, consult the implementation in provider.go and config.go.

Support for custom endpoints is on a best-effort basis. The underlying endpoint and default values for a resource can be changed at any time without being considered a breaking change.



Batching is not used for every resource/request type and can only group parallel similar calls for nodes at a similar traversal time in the graph during terraform apply (e.g. resources created using count that affect a single project). Thus, it is also bounded by the terraform -parallelism flag, as reducing the number of parallel calls will reduce the number of simultaneous requests being added to a batcher.

~> NOTE Most resources/GCP request do not have batching implemented (see below for requests which use batching) Batching is really only needed for resources where several requests are made at the same time to an underlying GCP resource protected by a fairly low default quota, or with very slow operations with slower eventual propagation. If you're not completely sure what you are doing, avoid setting custom batching configuration.

So far, batching is implemented for below resources:

The batching block supports the following fields.


You can extend the user agent header for each request made by the provider by setting the GOOGLE_TERRAFORM_USERAGENT_EXTENSION environment variable. This can be helpful for tracking (e.g. compliance through audit logs) or debugging purposes.

Example:

export GOOGLE_TERRAFORM_USERAGENT_EXTENSION="my-extension/1.0"

See RFC 9110 for format compliance of user agent header fields.