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
5 ways to improve DevEx and security for infrastructure provisioning
Still using manual scripting and provisioning processes? Learn how to accelerate provisioning using five best practices for Infrastructure Lifecycle Management.
Fix the developers vs. security conflict by shifting further left
Resolve the friction between dev and security teams with platform-led workflows that make cloud security seamless and scalable.
HashiCorp at AWS re:Invent: Your blueprint to cloud success
If you’re attending AWS re:Invent in Las Vegas, Dec. 2 - Dec. 6th, visit us for breakout sessions, expert talks, and product demos to learn how to take a unified approach to Infrastructure and Security Lifecycle Management.