A quick overview of the ephemeral resources and write-only feature in Terraform 1.11+

Boardgame

The night drapes the gloomy alleys in a veil of darkness. Jack moves silently through the shadows. The finest investigators of the gaslight era have gathered to catch him—before he slips away forever under cover of night.

Mr. Jack is a two-player deduction game where one player takes on the role of Mr. Jack, attempting to escape the city and erase all traces of his presence, while the other player controls the investigators working to unmask and capture him.

Each turn, players move characters, activate their unique abilities, and position them in either shadow or light. At the end of every round, witnesses reveal whether Jack remains visible—or has once again vanished into the darkness. For more information, visit: boardgamegeek

This short blog post explores ephemeral resources and the new write-only arguments introduced in Terraform v1.11.0. As you may know, Terraform stores all values—including sensitive ones like secrets—in plain text within the state file. While best practices recommend securing the state file , it’s now possible to go a step further: you can prevent secrets from being stored in the state file at all.

In this post, we’ll walk through a practical use case that shows how to securely pass secret values in your Terraform configuration using these new features—without leaving any trace in the state file.

Ephemeral resources

If you’ve recently searched for a resource in Terraform (e.g., AWS provider documentation), you may have noticed a new category alongside Resources and Data Sources: Ephemeral.

We’re already familiar with standard resources and data sources. But let’s take a closer look at ephemeral resources, a new concept introduced in Terraform 1.10.0. Ephemeral resources in Terraform are temporary, non-persistent objects designed to retrieve short-lived data—typically from systems like secrets managers. They’re similar to data sources in that they read from external systems, but with one major difference: they do not persist their output in the Terraform state file. This makes them especially valuable for handling sensitive information, such as secrets, that you don’t want stored in plaintext in your state.

Imagine you have a secret stored in AWS Secrets Manager. You might fetch the secret value using a traditional data source:

data "aws_secretsmanager_secret_version" "cloudynotes" {
  secret_id = "secret/test"
}

After applying this configuration, if you inspect the Terraform state file, you’ll find the secret value stored in plaintext:

Now let’s switch to an ephemeral resource to fetch the same secret:

ephemeral "aws_secretsmanager_secret_value" "cloudynotes" {
  secret_id = "secret/test"
}

Check the state file again—the secret value is no longer stored, preserving confidentiality and adhering to better security practices.

Ephemeral resource lifecycle

Another interesting aspect of ephemeral resources is their lifecycle, which differs from that of standard resources. If you take a look at the CLI output after running terraform plan or terraform apply, you’ll notice new lifecycle statuses like “opening” and “closing” when ephemeral resources are involved.

...
ephemeral.aws_secretsmanager_secret_version.cloudynotes: Opening...
ephemeral.aws_secretsmanager_secret_version.cloudynotes: Closing...
...

Here’s a brief overview of the ephemeral resource lifecycle:

• Opening: When Terraform needs the value, it “opens” the resource—similar to reading a secret from a secret manager.

• Renewing: If the resource has an expiration (e.g., a short-lived credential), Terraform may request a renewal from the provider.

• Closing: Once Terraform no longer needs the data (e.g., after the plan or apply phase is complete), it “closes” the resource, ensuring it doesn’t persist.

Write-only argument

With the release of Terraform v1.11.0, a new capability was introduced: write-only arguments. But what exactly do they do?

Some Terraform resources interact with sensitive values, such as those managed by AWS Secrets Manager, AWS SSM Parameter Store, or database credentials. Traditionally, Terraform stores these secret values in the state file—often in plaintext—which can pose a security risk. Consider the following scenario:

resource "aws_secretsmanager_secret" "cloudynotes" {
  name = "/cloudynotes/secret"
}

resource "aws_secretsmanager_secret_version" "cloudynotes" {
  secret_id     = aws_secretsmanager_secret.cloudynotes.id
  secret_string = random_password.cloudynotes.result
}

resource "random_password" "cloudynotes" {
  length           = 16
  special          = true
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

In this example, the secret would typically be stored in the Terraform state file.

Write-only arguments provide a way to avoid this. Terraform does not store these arguments in the plan or state file, which means:

• Their values are never persisted, reducing the risk of leaking secrets.

• The values are sent to the provider on every operation.

• Terraform cannot track changes to them directly [*].

[*] To work around the lack of tracking, Terraform introduces a companion concept: write-only version arguments. When you increment a version value manually, Terraform interprets it as a signal that the associated secret has changed.

Now let's changed the above example and use write-only and ephemeral resource type for password:

resource "aws_secretsmanager_secret" "cloudynotes" {
  name = "/cloudynotes/secret"
}

resource "aws_secretsmanager_secret_version" "cloudynotes" {
  secret_id                 = aws_secretsmanager_secret.cloudynotes.id
  secret_string_wo          = ephemeral.random_password.cloudynotes.result
  secret_string_wo_version  = 1
}

ephemeral "random_password" "cloudynotes" {
  length           = 16
  special          = true
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

This approach allows users to safely update sensitive values without exposing them in Terraform’s state management system, enabling better security practices when handling secrets.

Comments