new ephemeral resource: local_file

[bschaatsbergen]

Background

In Terraform 1.10, we introduced a new provider language construct: ephemeral, enabling provider plugin developers to create resources that do not persist any value in the Terraform state. Ephemeral resources expect all their dependencies to exist and are executed in both the plan and apply cycles. Additionally, 1.10 introduced the ability to reference ephemeral resources and values (variables) within provider and provisioner blocks. Building on this, in Terraform 1.11, we are prototyping write-only attributes, which would allow users to reference an ephemeral attribute directly in a resource’s input argument (as shown in the use cases below).

The purpose of this issue is to serve as a public record to exchange ideas. A possible outcome could be deciding not to implement this.

Use Cases or Problem Statement

The addition of an ephemeral local_file resource would provide a secure way to read sensitive files during Terraform plan and apply cycles, enabling users to reference file content directly in other language constructs (e.g. provider or resource blocks) while minimizing the risk of exposing sensitive data in the Terraform state. This ephemeral resource would simplify user workflows by eliminating the need for external tools or manual cleanup for temporary sensitive files.

Why this ephemeral resource?

While many resources require file content as input, there are valid reasons to avoid embedding large file content in your Terraform state.

Added, from a security best practices standpoint, it's strongly recommended that secrets be read and written through secret management solutions like HashiCorp Vault, rather than from the local filesystem. While educating users and guiding them away from reading secrets from their local filesystem is the ideal approach, I recognize that this transition won’t happen overnight. Introducing an ephemeral resource as a replacement for their current data source can help mitigate the immediate risk of sensitive data being exposed in the Terraform state, while also moving users one step closer to adopting a more secure approach.

Use cases

Writing a secret to HashiCorp Vault:

ephemeral "local_file" "example" {
  filename = "${path.module}/secret.json"
}

resource "vault_generic_secret" "example" {
  path          = "secret/example"
  data_json = ephemeral.local_file.example.content
}

Writing a secret to AWS Secret Manager:

ephemeral "local_file" "example" {
  filename = "${path.module}/secret.json"
}

resource "aws_secretsmanager_secret_version" "example" {
  secret_id     = aws_secretsmanager_secret.example.id
  secret_string = ephemeral.local_file.example.content
}

Writing a secret through other provider resources: kubernetes_secret_v1, google_secret_manager_secret_version, etc.

Proposal

Introduce an ephemeral resource: local_file with a similar implementation to the existing local_file data source.

How much impact is this issue causing?

Medium

Additional Information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[ned1313]

What would the advantage be over using the file or templatefile functions to read data into a write-only attribute?