Terraform 1.11 adds ephemeral values, write-only arguments feature.

HashiCorp Terraform 1.11: Enhancing Security and Functionality

HashiCorp has officially launched Terraform 1.11, a significant update that introduces new features and improvements to enhance the security and functionality of Terraform. This latest version is now available for download and can be utilized within the HashiCorp Cloud Platform (HCP Terraform). One of the standout features of this release is the introduction of "write-only arguments," which allow users to handle ephemeral values more effectively within specific managed resource arguments.

Enhancing Ephemeral Values with Write-Only Arguments

With the release of Terraform 1.10, HashiCorp introduced the concept of ephemeral values to provide a more secure method for handling sensitive data, such as private keys and API tokens. These ephemeral values are designed to prevent sensitive information from being stored in Terraform’s artifacts, such as the plan or state files. In Terraform 1.10, the following features were introduced:

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

  However, the use of ephemeral values was restricted to other ephemeral contexts, such as input variables, output values, provider and provisioner blocks, and ephemeral resources.

  With Terraform 1.11, the use of ephemeral values has been extended to managed resources through the introduction of write-only arguments. Write-only arguments are resource arguments that can only be written to and not read. Like ephemeral values, these arguments are not saved in Terraform’s plan or state files. This enhancement allows users to securely pass sensitive information, such as generated passwords or fetched tokens, directly to managed resources without the risk of exposure in Terraform’s artifacts.

  Practical Application of Write-Only Arguments
  

  To better understand the new feature, consider an example where ephemeral resources and write-only arguments are used to provision an AWS RDS instance while generating a random password with the random provider. In this configuration, the ephemeral resource random.password generates a random password, which is then securely passed to the password_wo argument of the managed aws_db_instance resource.

  Write-only arguments differ from other managed resource arguments in several key ways:

  1. They accept ephemeral values.
  2. Their values are never stored in Terraform’s plan or state files.
  3. Because the values of write-only arguments are not persisted, they are updated using version-specific attributes (e.g., value_wo_version), which are stored in the state. To update a write-only argument, users must increment the version argument’s value in the configuration.

     This configuration 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 artifacts.

     Availability in Terraform 1.11
     

     The current release supports write-only arguments in various managed resources, including:

• AWS
• Azure
• Google Cloud
• Kubernetes
• Helm
  

  Partner Spotlight
  

  The true power of Terraform’s language features is realized when technology partners extend them to their providers. To fully address the challenge of "secrets in state," every Terraform provider must handle sensitive credentials as ephemeral, short-lived constructs. Notable partners like Juniper, Palo Alto Networks, and Fortinet are leading the way. For instance, Juniper’s apstra_api_token, Palo Alto Networks’ panos_api_key and panos_vm_auth_key, and Fortinet’s fortiflexvm_groups_nexttoken provide more secure, temporary credentials that minimize exposure.

  For those who missed the workshop on implementing ephemeral values in providers, a recording is available for viewing. HashiCorp encourages tech partners to explore implementing ephemeral values to enhance security across the Terraform ecosystem.

  Upgrades to Terraform Tests
  

  Terraform 1.11 also includes several other enhancements outlined in the changelog, particularly within the test framework:

• State Key Attribute: Terraform tests now feature a new state_key attribute for run blocks, allowing test authors to control which internal state file should be used for the test run. This enables multiple run blocks to target the same infrastructure, such as using a setup module and executing multiple tests on it.
• Mocked or Overridden Values: Test runs now support using mocked or overridden values during unit test runs (e.g., with command = "plan"). Users can set override_during = plan in the test configuration to use overridden values during the plan phase, with the default being override_during = apply.
• JUnit XML Format: The -junit-xml CLI flag for the terraform test command is now generally available, allowing the command to create a test report in JUnit XML format.
  

  Next Steps
  

  To begin using HashiCorp Terraform 1.11, users can download the latest version from the HashiCorp website. This release has been made possible through valuable feedback from the community, including contributions via GitHub issues, HashiCorp Discuss forums, and customer input. The continuous support and engagement from the community are greatly appreciated.

  For more detailed information, users are encouraged to refer to the official Terraform documentation and explore the changelog for a comprehensive list of all new features and improvements.

For more Information, Refer to this article.