Terraform provider for Google Cloud 7.0 is now GA
Version 7.0 of the HashiCorp Terraform Google Cloud provider adds new ephemeral resources, write-only attributes, and validation logic.
We are excited to announce the general availability of version 7.0 of the Terraform provider for Google Cloud. We want to extend a huge thank you to our community of users and contributors. Your feedback and contributions are invaluable in making the provider better with each release. The provider's growth has been phenomenal, recently surpassing 1.4 billion downloads and now supporting over 800 resources and 300 data sources.
» What's new since 6.0
Since the last major version release, we have focused on introducing new ways to manage sensitive data securely within your Terraform workflows. Version 7.0 continues to expand on these security-first features, which are powered by enhancements in recent Terraform versions.
-
Ephemeral resources: Introduced in Terraform 1.10, ephemeral resources allow users to use temporary resources without storing any of their data in the Terraform state file. This is perfect for short-lived credentials like access tokens. The Google Cloud provider is actively adding new ephemeral resources, such as
google_service_account_access_token
, to help users securely manage authentication and other sensitive operations. -
Write-only attributes: Supported since Terraform 1.11, write-only attributes prevent sensitive inputs, like passwords or API keys, from being written to a state file. This significantly reduces the risk of exposing secrets. We are continuing to add write-only attribute variants (e.g.
password_wo
) to more resources, giving users a more secure way to manage credentials for resources likegoogle_sql_user
.
Here’s an example of using an ephemeral resource to generate a temporary access token for provider impersonation. Because the token is fetched using an ephemeral resource rather than a traditional data source, its sensitive value is used by Terraform but never saved to the state file.
# The ephemeral resource fetches a short-lived token
ephemeral "google_service_account_access_token" "impersonated" {
target_service_account = "your-sa@your-project.iam.gserviceaccount.com"
scopes = ["https://www.googleapis.com/auth/cloud-platform"]
lifetime = "300s"
}
# The token is then used to configure a provider alias
provider "google" {
alias = "impersonated"
access_token = ephemeral.google_service_account_access_token.impersonated.access_token
}
And here is how to use a write-only attribute to set a password for a SQL database user. The password value is sent to the API but is not stored in the state file.
# Define the password as a sensitive variable to avoid saving it in plain text
variable "db_user_password" {
type = string
sensitive = true
# This value would be passed in via a secure method
# like an environment variable or a .tfvars file
}
resource "google_sql_user" "db_user" {
name = "my-app-user"
instance = google_sql_database_instance.main.name
host = "%"
# The 'password_wo' attribute uses the sensitive variable,
# ensuring the value is never stored in the Terraform state file.
password_wo = var.db_user_password
password_wo_version = 1
}
» Changes and deprecations in 7.0
In a major version release like 7.0, we introduce changes and deprecations to improve the provider’s overall quality, consistency, and security. Our goal is to refine the user experience by addressing ambiguity and aligning more closely with the behavior of Google Cloud.
The changes in this release center on a few key themes:
-
Improved validation and reliability: We have strengthened the provider's validation logic to catch configuration errors earlier. In some resources, attributes that were functionally required by the Google Cloud API are now explicitly marked as such in the schema. This "fail-fast" behavior ensures that users receive immediate feedback during a
terraform plan
rather than encountering an unexpected error during anapply
, making infrastructure deployments more predictable. -
API alignment and modernization: This release includes deprecations to align with the latest versions of Google Cloud APIs. For example, when an underlying API is updated by Google, we deprecate attributes that are no longer configurable to ensure Terraform configuration accurately reflects the resource's true behavior. This prevents confusion and guarantees that the provider remains stable and secure for the long term.
These refinements, while requiring attention during an upgrade, are essential for creating a more robust and intuitive provider.
» Upgrading to version 7.0
As this is a major release, it includes breaking changes that may require you to update your Terraform configurations. We have created a comprehensive guide to walk you through the process. For detailed instructions and a full list of changes, please review the Terraform provider for Google Cloud 7.0 Upgrade Guide.
To explore all the provider's features, visit the Google Cloud provider page on the Terraform Registry. As always, we welcome your feedback and contributions in the provider’s GitHub repository.
If you are currently using Terraform Community Edition or are completely new to Terraform, try HCP Terraform for free today.
Sign up for the latest HashiCorp news
More blog posts like this one

How to enable developer self-service at scale with Terraform and Waypoint
Learn how to simplify Terraform self-service with HCP Waypoint’s features for building golden deployment workflows.

5 lessons from Moneybox’s Terraform journey
Learn about Moneybox’s infrastructure-scaling transformation, and how the transition to HCP Terraform supported it.

Terraform now supports assigning agent pools at the project level
HCP Terraform and Terraform Enterprise users can now assign default agent pools at the project level, offering a more scalable and secure approach to agent pool configuration.