Terraform 1.11 brings ephemeral values to managed resources with write-only arguments

Today, we are announcing the general availability of HashiCorp Terraform 1.11, which is ready for download and immediately available for use in HCP Terraform. This version introduces write-only arguments, which let you use ephemeral values in specific managed resource arguments.

»Extending ephemeral values with write-only arguments

In Terraform 1.10, we introduced ephemeral values to provide a more secure way to handle sensitive data, such as private keys, API tokens, and other secrets. Ephemeral values in Terraform are not persisted in artifacts like the plan or state file. Terraform 1.10 introduced:

1. Ephemeral input variables and output values for temporary or sensitive data, such as short-lived tokens or session identifiers.
2. Ephemeral resources, a new language construct that allows Terraform to temporarily reference external data by opening and closing a remote object.

In Terraform 1.10, ephemeral values could only be used in other ephemeral contexts, such as:

• Ephemeral input variables
• Output values
• Provider and provisioner blocks
• Ephemeral resources

With Terraform 1.11, you can use ephemeral values in managed resources through the introduction of write-only arguments.

Write-only arguments are arguments in a resource that can only be written to, and not read. Similar to ephemeral values, write-only arguments are not stored in Terraform artifacts like the plan or state file.

This enhancement makes it possible to securely pass secrets, such as a generated password or a fetched token, directly to managed resources without risking exposure in the state file or plan file.

By extending ephemeral values to managed resources, Terraform 1.11 strengthens the security of workflows involving sensitive data, ensuring your secrets remain secure across input variables and output values, ephemeral resources, and write-only arguments in managed resources.

»Write-only arguments in practice

To illustrate this new feature, let’s look at an example. You’re using ephemeral resources and write-only arguments in Terraform to provision an AWS RDS instance and generate a random password with the random provider. In the configuration below, the ephemeral resource random.password generates a random password, which is then passed to the password_wo argument of the managed aws_db_instance resource.

Write-only arguments are different from other managed resource arguments in several ways:

1. They accept ephemeral values.
2. Their values are never persisted in Terraform’s plan or state files.
3. Since the values of write-only arguments are not persisted, write-only arguments are updated using their version-specific attributes (e.g. value_wo_version). The values of the version-specific attributes get stored in state. To trigger an update of a write-only argument, increment the version argument's value in your configuration.

The configuration below ensures that the password remains ephemeral throughout the workflow — from its generation in the ephemeral resource to its secure use in the RDS instance with the write-only argument — without being exposed in Terraform's plan file or state file.

»Available with Terraform 1.11

These are the current write-only arguments supported in the following managed resources:

»AWS

• aws_db_instance
  • Attribute: password_wo
• aws_secretsmanager_secret_version
  • Attribute: secret_string_wo
• aws_rds_cluster
  • Attribute: master_password_wo
• aws_redshift_cluster
  • Attribute: master_password_wo
• aws_redshiftseverless_namespace
  • Attribute: admin_user_password_wo
• aws_docdb_cluster
  • Attribute: master_password_wo
• aws_ssm_parameter
  • Attribute: value_wo
• And more!

»Azure

• azurerm_mssql_server.administrator
  • Attribute: administrator_login_password_wo
• azurerm_mysql_flexible_server
  • Attribute: administrator_password_wo
• azurerm_mssql_job_credential
  • Attribute: password_wo
• azurerm_postgresql_flexible_server
  • Attribute: administrator_password_wo
• azurerm_postgresql_server
  • Attribute: administrator_login_password_wo

»Google Cloud

• google_secret_manager_secret_version
  • Attribute: secret_data_wo
• google_sql_user
  • Attribute: password_wo
• google_bigquery_data_transfer_config
  • Attribute: sensitive_params.secret_access_key_wo

»Kubernetes

• Kubernetes_secret_v1
  • Attributes: data_wo, binary_data_wo

»Helm

• helm_release
  • Attributes: set_wo

»Partner spotlight

Terraform language features truly solve problems only when our tech partners extend them to their providers. Addressing the ‘secrets in state’ challenge fully for our mutual users requires every Terraform provider to handle sensitive credentials as ephemeral, short-lived constructs.

That’s why we’d like to give a massive shoutout to our tech partners, Juniper, Palo Alto Networks, and Fortinet for leading the way! With Juniper’s apstra_api_token, Palo Alto Networks’ panos_api_key and panos_vm_auth_key, and Fortinet’s fortiflexvm_groups_nexttoken, these providers offer more secure, temporary credentials that minimize exposure.

Missed our workshop on implementing ephemeral values in your providers? Watch the recording here.

We encourage our partners to explore implementing ephemeral values in their providers and enhance security across the ecosystem!

»Upgrades to Terraform tests

Terraform 1.11 includes other enhancements outlined in the changelog, including new features in the test framework:

• Terraform tests have a new state_key attribute for run blocks, allowing test authors control over which internal state file should be used for the current test run. This allows multiple run blocks to target the same infrastructure. For example, you can use a setup module and execute multiple tests on it by utilizing the state_key attribute.
• Terraform test runs now support using mocked or overridden values during unit test runs (e.g. with command = "plan"). Set override_during = plan in the test configuration to use the overridden values during the plan phase. The default value is override_during = apply.
• The -junit-xml CLI flag for the terraform test command is now generally available. This flag allows the command to create a test report in JUnit XML format.

»Next steps

To get started with HashiCorp Terraform:

• Download Terraform 1.11
• Sign up for a free HCP Terraform account
• Get hands-on with the Upgrade RDS major version tutorial at HashiCorp Developer

As always, this release wouldn’t have been possible without the valuable feedback from the community, including contributions via GitHub issues, HashiCorp Discuss forums, and our customers. Thank you, everyone!