Terraform, Google Cloud, and Secrets
In Google Cloud, Secret Manager is great for storing sensitive data—but keeping secrets out of Terraform state, logs, and version control is a challenge. Terraform 1.11 introduced ephemeral resources and write-only arguments to fix that. Here’s how.
Ephemerality
Ephemerality in computing refers to the ability to create something that is short-lived or temporary — a piece of data that exists only for a brief period and is discarded once its purpose is fulfilled. In Terraform, this concept was introduced to manage sensitive data or open a connection in a way that ensures it doesn’t persist beyond its immediate use. in Terraform 1.11, HashiCorp, implemented new language constructs that track values only at runtime, making them transient and, therefore, ephemeral by design.
Ephemeral resources are Terraform resources that are essentially temporary. They are responsible for reading data from a source such as a secrets manager, or opening a connection, and their attributes can be referenced in other places without persisting anything to the Terraform plan artifact or state file.
It’s important to note that ephemeral resources require all their dependencies to exist because they always run during both the plan and apply stages. If an ephemeral resource attempts to read a secret from a secrets manager that doesn’t exist, it will result in an error. However, Terraform can defer the execution of an ephemeral resource to the apply stage if one of its input arguments references a value that is not yet known at the plan stage but will be determined during apply.
Here’s an example of an ephemeral password resource with no dependencies, executed during both plan and apply:
This password exists only in memory during execution. Newly generated on every plan and apply, never stored in state.
We’ll cover how to prevent this ephemeral password from rotating unnecessarily on each run—but first, let’s look at write-only arguments.
Write-Only Arguments
Write-only arguments are special attributes on managed resources that users can set, but Terraform doesn’t store them in the plan or state. They’re typically used for sensitive inputs—like passwords or API tokens—to avoid leaking secrets into persistent infrastructure metadata.
The secret_data_wo is an ephemeral, write-only argument—it accepts sensitive input without persisting it in plan or state files. The secret_data_wo_version acts as the control—Terraform tracks this version to decide when to update the secret.
Since write-only values can’t be compared directly (Terraform doesn’t store them), the version acts as a signal. Without this mechanism, every plan or apply would trigger a secret rotation, even when unnecessary.
Using the Secret
Think of a database user: it should not get a new password every time Terraform runs—only when the version updates. That’s the whole point of using version-controlled ephemeral values.
Connection Strings
Now we can securely construct connection strings at runtime using ephemeral values, without leaking secrets to state or logs:
Version Synchronization
Notice how the secret_data_wo_version references google_secret_manager_secret_version.cloud_sql_admin.secret_data_wo_version. This ensures that the password gets updated only when the password changes, as they’re tied to the same version. This way, the connection string only updates when the password changes, keeping everything in sync without unnecessary rotations.
Without this synchronization, you could end up with a situation where the connection string references an outdated password, leading to connection failures.
Consuming Secrets
Now that we have our secrets set up, we can consume them in our application. For example, if you’re deploying a Cloud Run service, you can reference the secret directly in the container environment variables without exposing it in your Terraform state.
This is how secrets should behave: temporary, purpose-built, and gone when they’re no longer needed. We’ve spent a long time working around the challenges of secrets in state—but with ephemeral support, we don’t have to anymore.