gcs

Stores the state as an object in a configurable prefix in a pre-existing bucket on Google Cloud Storage (GCS). The bucket must exist prior to configuring the backend.

This backend supports state locking.

Example Configuration

terraform {
  backend "gcs" {
    bucket  = "tf-state-prod"
    prefix  = "terraform/state"
  }
}

Data Source Configuration

data "terraform_remote_state" "foo" {
  backend = "gcs"
  config = {
    bucket  = "terraform-state"
    prefix  = "prod"
  }
}

# Terraform >= 0.12
resource "local_file" "foo" {
  content  = data.terraform_remote_state.foo.outputs.greeting
  filename = "${path.module}/outputs.txt"
}

# Terraform <= 0.11
resource "local_file" "foo" {
  content  = "${data.terraform_remote_state.foo.greeting}"
  filename = "${path.module}/outputs.txt"
}

Authentication

IAM Changes to buckets are eventually consistent and may take upto a few minutes to take effect. Terraform will return 403 errors till it is eventually consistent.

Running Terraform on your workstation.

If you are using terraform on your workstation, you will need to install the Google Cloud SDK and authenticate using User Application Default Credentials.

User ADCs do expire and you can refresh them by running gcloud auth application-default login.

Running Terraform on Google Cloud

If you are running terraform on Google Cloud, you can configure that instance or cluster to use a Google Service Account. This will allow Terraform to authenticate to Google Cloud without having to bake in a separate credential/authentication file. Make sure that the scope of the VM/Cluster is set to cloud-platform.

Running Terraform outside of Google Cloud

If you are running terraform outside of Google Cloud, generate a service account key and set the GOOGLE_APPLICATION_CREDENTIALS environment variable to the path of the service account key. Terraform will use that key for authentication.

Impersonating Service Accounts

Terraform can impersonate a Google Service Account as described here. A valid credential must be provided as mentioned in the earlier section and that identity must have the roles/iam.serviceAccountTokenCreator role on the service account you are impersonating.

Encryption

Customer-supplied encryption keys

To get started, follow this guide: Use customer-supplied encryption keys

If you want to remove customer-supplied keys from your backend configuration or change to a different customer-supplied key, Terraform cannot perform a state migration automatically and manual intervention is necessary instead. This intervention is necessary because Google does not store customer-supplied encryption keys, any requests sent to the Cloud Storage API must supply them instead (see Customer-supplied Encryption Keys). At the time of state migration, the backend configuration loses the old key's details and Terraform cannot use the key during the migration process.

Customer-managed encryption keys (Cloud KMS)

To get started, follow this guide: Use customer-managed encryption keys

If you want to remove customer-managed keys from your backend configuration or change to a different customer-managed key, Terraform can manage a state migration without manual intervention. This ability is because GCP stores customer-managed encryption keys and are accessible during the state migration process. However, these changes do not fully come into effect until the first write operation occurs on the state file after state migration occurs. In the first write operation after state migration, the file decrypts with the old key and then writes with the new encryption method. This method is equivalent to the rewrite operation described in the customer-supplied encryption keys section. Because of the importance of the first write to state after state migration, you should not delete old KMS keys until any state file(s) encrypted with that key update.

Customer-managed keys do not need to be sent in requests to read files from GCS buckets because decryption occurs automatically within GCS. This process means that if you use the terraform_remote_state data source to access KMS-encrypted state, you do not need to specify the KMS key in the data source's config object.

Configuration Variables

The following configuration options are supported: