HashiCorp has released Terraform 1.10, which introduces ephemeral values - a concept designed to protect sensitive information, such as passwords, which is often required to provision infrastructure with Terraform.
Considered a weakness in earlier versions, the technique of storing secrets within Terraform plan and state files, where they would often be in plaintext, has now been superseded by ephemeral values. These provide a secure alternative by ensuring that sensitive data are not persisted in any Terraform artefacts.
Key features of ephemeral values include:
- Ephemeral input and output variables: Allows marking variables that need to exist only temporarily, such as short-lived tokens or session identifiers.
- Ephemeral resources: A new resource mode that can be created or fetched separately for each Terraform phase, used to configure objects, and then explicitly closed.
The blog demonstrates ephemeral values through an example involving AWS Secrets Manager. Previously, secrets fetched through data sources would be stored in the Terraform plan and state files, but with ephemeral values, the secret is retrieved and used without being permanently stored anywhere else.
Ephemeral resources are available for major cloud providers, including AWS, Azure, and Kubernetes, though the provider must support the required resources. Some in the community found this ambiguous, and pointed out that Hashicorp's own Vault provider does not yet appear to have ephemeral resources. Google Cloud support has also not yet been released, but it is scheduled for December 9th. The providers and their corresponding ephemeral resources are:
- AWS:
aws_secretsmanager_secret_version,aws_lambda_invocation - Azure:
azurerm_key_vault_secret, azurerm_key_vault_certificate - Kubernetes:
kubernetes_token_request,kubernetes_certificate_signing_request
In a LinkedIn post, Achim Christ explores the motivation for ephemeral values - explaining how it is an alternative to encrypting the Terraform state file:
Folks at HashiCorp have argued that encrypting the entire state is not ideal, as it introduces another secret — the cryptographic key — which must also be managed. Thus, traditional state encryption may still expose sensitive data if compromised Terraform environments allow unauthorized access, a risk known as "secret sprawl".
- Achim Christ
However, some commenters don't believe this is a good solution, with Alexandre Nédélec suggesting on Bluesky that secrets encryption may be a better approach.
Not really convinced by ephemeral values of Terraform 1.10. Secrets encryption just seem a better solution. Pulumi does it. OpenTofu allows state encryption. I don't understand why Terraform does not do it.
Christ goes on to give examples of how to use ephemeral inputs, outputs and variables. He also explains the use case for write-only attributes, which are planned for Terraform 1.11. He summarises that "the concept of ephemerality is a valuable addition to the core Terraform configuration language". Other reaction has also been positive, with Marko Bevc speaking of the benefits around safely storing passwords in a post on Bluesky.
Quite excited about #Terraform v1.10 release . It's introducing ephemeral resources and values, which are read anew during each phase of Terraform evaluation, and aren't persisted in state. I think this gives us a better story around safely storing sensitive values.
In addition to secret management improvements, Terraform 1.10 includes some performance enhancements, improving Terraform plan and apply operations where a large number of resource instances are used.
It's as yet unclear whether Terraform fork OpenTofu will be implementing ephemeral values. An issue is, however, open on OpenTofu's GitHub account to track this.
Terraform 1.10 is now ready for download and is also available in HCP Terraform.
