Terraform 1.10 improves handling secrets in state with ephemeral values
Terraform 1.10 is generally available, and it includes ephemeral values along with improvements to plan and apply performances.
Today, we are announcing the general availability of HashiCorp Terraform 1.10, which is ready for download and immediately available for use in HCP Terraform. This version introduces ephemeral values, for secure secrets handling and other improvements.
» Ephemeral values to enable secure handling of secrets
Terraform’s management of infrastructure involves handling secrets, such as private keys, certifications, API tokens, etc. As an example, a data source may be used to fetch a secret and write it to a managed resource’s attribute. Or a secret is generated by a resource type (e.g. a random password) and is written to another resource type like a dedicated secrets manager.
Today, these secrets get persisted in the plan or state file. Since the secrets are stored in plaintext within these artifacts, any mismanaged access to the files would compromise the secrets. We’ve been working on a feature to improve the security of this workflow, and it’s now ready for Terraform 1.10..
To enable secure handling of secrets, we’re introducing ephemeral values. These values are not stored in any artifact. Not the plan file or the statefile. They are not expected to remain consistent from plan to apply, or from one plan/apply round to the next. Ephemeral values encompass the following language constructs:
- Ephemeral input variables and output variables: Similar to marking a value as
sensitive
, you can now mark the input variables and output variables asephemeral
. Marking an input variable asephemeral
is useful for data that only needs to exist temporarily, such as a short-lived token or session identifier. - Ephemeral resources: A new third resource mode alongside managed resource types and data resources. These are declared with
ephemeral
blocks, which declare that something needs to be created or fetched separately for each Terraform phase, then used to configure some other ephemeral object, and then explicitly closed before the end of the phase. - Managed resources’ write-only attribute: A new attribute for managed resources, which has a property that can only be written to, not read. Write-only attributes will be available in Terraform 1.11.
Ephemeral values represent an advancement in how Terraform helps you manage your infrastructure. Whether you are using it to generate credentials, fetch a token, or setting up a temporary network tunnel, ephemeral values will ensure that these values are not persisted in Terraform artifacts.
» Ephemeral values in practice
In this example, an ephemeral resource is being used to fetch a secret from AWS Secrets Manager, which is then used to initialize the PostgresSQL provider. Before Terraform 1.10, a data source was used to fetch the secret, in which case the secret value would be stored in both the plan and state file. With the introduction of ephemeral values, the secret is now kept secure because it is no longer stored in any artifact.
provider "aws" {
region = "eu-west-2"
}
data "aws_db_instance" "example" {
db_instance_identifier = "testdbinstance"
}
ephemeral "aws_secretsmanager_secret_version" "db_master" {
secret_id = data.aws_db_instance.example.master_user_secret[0].secret_arn
}
locals {
credentials = jsondecode(ephemeral.aws_secretsmanager_secret.db_master.secret_string)
}
provider "postgresql" {
host = data.aws_db_instance.example.address
port = data.aws_db_instance.example.port
username = local.credentials["username"]
password = local.credentials["password"]
}
resource "postgresql_database" "db" {
name = "new_db"
}
» Available in Terraform 1.10
The Terraform 1.10 release includes ephemeral input and output variables, ephemeral resources, and new functions (ephemeralasnull
, terraform.applying
). There are currently ephemeral resources available for three different providers:
- 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
Ephemeral resources are currently available in the AWS, Azure, Kubernetes, and random providers, and will be supported in the Google Cloud provider on December 9th. Ephemeral resources in Google Cloud will include:
- Google Cloud:
google_service_account_access_token
,google_service_account_id_token
,google_service_account_jwt
,google_service_account_key
» Other improvements and next steps
Terraform 1.10 also includes other enhancements outlined in the changelog. One key inclusion is more performance improvements:
- Performance improvements: We refactored plan changes and reduced repeated decoding in resource state to improve plan and apply performances. This will help mitigate performance issues when a large number of resource instances are evaluated.
To get started with HashiCorp Terraform:
- Download Terraform 1.10
- Sign up for a free HCP Terraform account
- Read the Terraform 1.10 upgrade guide
- Get hands-on with tutorials at HashiCorp Developer
As always, this release wouldn't have been possible without the great community feedback we've received via GitHub issues, HashiCorp Discuss forums, and from our customers. Thank you!
Sign up for the latest HashiCorp news
More blog posts like this one
Terraform delivers launch-day support for Amazon S3 Tables, EKS Hybrid Nodes, and more at re:Invent
The Terraform provider for AWS now enables users to manage a variety of new services just announced at re:Invent.
HashiCorp at re:Invent 2024: Infrastructure Lifecycle Management with AWS
A recap of HashiCorp infrastructure news and developments on AWS from the past year, from a new provider launch to simplifying infrastructure provisioning and more.
Simplify policy adoption in Terraform with pre-written Sentinel policies for AWS
HashiCorp introduces a new pre-written policy library co-developed with AWS, aiming to reduce the barrier of adoption for policy as code infrastructure workflows.