Terraform: FR: env("ENV_VAR") interpolation function for reading environment variables

[bmoylan]

An interpolation function which reads an environment variable at runtime.

my_value = "${env("MY_VALUE")}"

If this is accepted I'd be willing to implement it.

[apparentlymart]

Hi @bmoylan! Thanks for this feature request.

It is an intentional design decision not to allow arbitrary reading of the environment in a Terraform configuration, since it makes it difficult to fully understand the inputs to a module -- any child module would be able to "reach around" and access environment variables, whereas today they are only able to access data provided by the caller, intentionally.

There's a more detailed version of this rationale in the comments of #14166, if you're interested. That also references another issue where there was discussion of a potential future enhancement to allow variable defaults to be derived from environment variables, thus allow the _root_ module to be configured from the environment without all the other drawbacks. For now, the TF_VAR_name environment variable scheme is the recommended way to set root module Terraform variables from the environment, which is a little less convenient (need to use a wrapper script in order to access a variable _not_ named TF_VAR_ but proved easier to implement within the current architectural constraints.

I hope this all makes sense. I'm going to close this for these reasons. Thanks again for taking the time to file this feature request.

[bmoylan]

Thanks @apparentlymart for the response and justification! This makes sense. I searched around for old issues/PRs but that commit must have slipped past me.

My main use case was for providers which don't detect environment variables via code (like AWS does) and where I don't want to put secret credentials into tfvars.

[apparentlymart]

Generally speaking we recommend to use environment variables for credentials (either directly or via paths to files on disk), so if you see a provider that doesn't allow that I think a PR to fix that -- or even just an feature request to point it out --- would be appreciated! Provider config is an exception to the above because most provider settings are cross-cultural, identifying the user running Terraform, etc.

The providers now live in separate repositories in the terraform-providers organization, so issues and PRs for them should be opened in those repos.

Thanks again!

[duckie]

Hello there

I understand the arguments. However:

• Subtemplates can still "reach around" with the file()interpolation function, thus not respecting the rationale.
• Using TF_VAR syntax can also make child template use the environment without the knowledge of the caller.
• Plugins do make use of env variables in their implementation, thus breaking the rationale too.

I think this should be reconsidered, as it is more annoying than actually useful.

[9horses]

Another way to "reach around" is via an external data source.

In fact, with this data source, you can implement this FR in one line if jq is accessible from terraform:

data "external" "env" { program = ["jq", "-n", "env"] }

Access env vars this way: "${data.external.env.result.ENV_VAR}"

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.