Variables and Secrets

Terraform Variables & Environment Variables

Using an infrastructure-as-code model, variables are used to customize certain aspects of a configuration for a specific deployment, without having to change the code. In this way, a single configuration can be used in different contexts to create different deployments.

Variables can be anything from ports and IPs to cloud credentials, availability zones, and images.

env0 supports two types of variables:

• Terraform Variables (also called Input Variables) - These are defined in the Terraform configuration files. Their values are set by env0 when running IaC commands
• Environment Variables - These are set by env0 in the shell running IaC commands and Custom Flows.

📘

Built-in Terraform/Terragrunt Environment Variables Support

Terraform and Terragrunt supports various environment variables to alter the behavior of the deployment. You can add those as environment variables inside the env0 platform as well where the name and the appropriate value.
See all the supported Terraform environment variables and the relevant Terragrunt environment variables.

For example:
If you wish to perform a state migration you can add the TF_CLI_ARGS_init environment variable and as a value put -migrate-state.
You can read more about TF_CLI_ARGS here

Terraform Variables and Environment Variables are both managed by the user in env0.

Variables and Scopes in env0

env0 uses hierarchical scopes to manage variables (both Terraform Variables and Environment Variables). You can set variables for an Organization, a Template, a Project, or a specific Environment.

Each scope inherits the variables defined in the higher scopes. Hence, a template will have all the variables that are set for the organization. A project will have all the variables that are set for the organization, or any parent projects it has. And a new environment will have all the variables that are set for the project, template, and organization.

You can change the value of a variable inherited from a higher scope, but not its name.

The different variable scopes reflect the fact that variables are used for different purposes and might be set by different people.

📘

Example

• An administrator sets cloud credentials in the Organization scope to apply to all the environments managed in an organization.

• A DevOps engineer creates a new template. They want to have the option for the user to select from two different machine sizes. Therefore they use the same Terraform configuration, with the instance type set as a variable, and create two templates, each with a different value for the instance size variable.

• A developer creates a new environment. They don't need to know the credentials, or set the instances sizes. They choose a template and let env0 use the variables defined in the higher scopes. They can, however, still make further customizations by overriding a Terraform Variable which specifies which port to use.

Variables Value Types

The env0 platform supports several value types of variables:

Free Text

This is the most-common variable value type that holds a plain text value. To accommodate your variable with a value, simply type your desired text or leave it blank. This value type also supports setting it as secrets.

HCL Format

This type allows you to define complex terraform values - similar to what can you define in the .tf file
We support all complex terraform types
This format is only available under Terraform Variables section

Examples for HCL values:

{ objects_list = [{ key = "object1" 
                    value = "value1"},
                   { key = "object2" 
                    value = "value2"}] }

["value1", "value2"]

JSON Format

This type allows you to define complex terraform values - as JSON format
We support all complex terraform types
This format is only available under Terraform Variables section

Examples for JSON values:

{ "objects_list":  [{ "key": "object1", "value":"value1"},
                    { "key": "object2", "value": "value2"}]}

Dropdown List

This is a variable value that is configured with a predefined set of options that you can select as a value. This allows you to govern your specific variable with a dropdown of available options that any other organization or user can select from. Dropdown List variables can be re-selected in lower scopes but can be configured (aka add/remove options) only in their original scope.

To add/remove options of a Dropdown List variable:

1. Add a new Dropdown List variable.
2. Click on its value input and a new select dropdown will be opened.
3. To add an option, type the desired option and click + Add Option button on the opened select's footer.
4. To remove an existing option, hit the Trash icon next to the relevant option.
5. Don't forget to hit the save button to commit your changes.

Variable Settings

You can configure advanced settings for every variable in our system. by opening the advanced settings form.
The rightmost icon in the variable line.

Required Variable

This setting means that you can't start the deployment without any value for this variable.
You can create a variable in higher scope (organization, template, project) which mark required without a value, but you must insert a value before the deployment.

Read Only Variable

This setting means you locked this variable for all lower scopes. When you configure it none of the lower scopes can override this variable.

A good example for using in this setting - when the organization admin wants to enforce using in the same stage and identifier for all environments in the organization. he can enable it and no one can override it or delete it.

Regular Expression Validation (only for Free Text variables)

You can define a regular expression that value should match. If you set the regular expression in upper scope, you can keep the value empty - the validation will be enforced in lower scope.

Variables Description

Variables have an optional description that is editable only at the scope they are created, and viewable on lower scopes. Unlike the values, the description cannot be overridden.

Load Variables From Terraform Code

On Terraform Variables scope, clicking on Load Variables From Code will load the variables from your Terraform code directory - all the default values.

Be aware that variables loaded will not be saved until the Save Button is clicked, and only "string" type variables will be loaded, as is generally done in Terraform Variables.

👍

Complex value

All the default complex values - we will load them as JSON format type. and you will able to edit them as JSON.

Secrets

For security reasons, some variables needed for flow execution should not be exposed to user executing flows. This is Secrets Management. The most common use case for secrets management is cloud credentials.

In env0, secrets are variables that are marked as sensitive. A sensitive variable has its value masked after you save it. If you'd like to change an existing sensitive variable, simply click on the masked value to clear it, type in the new secret value, and then save.

Like other variables, secrets are inherited and can be defined in any scope.

📘

Secrets in a Self-Hosted Agent

If your organization is managed by a Self-Hosted Agent, then you would not be allowed to create secrets via the "Sensitive" checkbox.
You can have a variable point to an existing variable in one of the following:

1. AWS Secret Manager
2. GCP Secret Manager
3. Azure Key Vault
4. HashiCorp Vault

You can Read more on how to configure it here

Manage Variables

To manage variables at the organization scope, select the Variables tab on the main screen. This shows a list of the organization's Environment Variables and Terraform Variables. You can edit their names or values, and add new ones.

Don't forget to save any changes before you leave the page, or your changes will be lost.

To manage variables at the Template level, go to the Template tab and select the template you are interested in. Click Settings, and then select the Variable tab. Here you can modify variables for the template.

At the environment level, you can set the variables just before deployment. When you create a new environment or redeploy, a pop up is opened, with environment details to fill in. Select the Variable section, and modify the variables for this specific environment.

For an environment that already exists, you edit the variables settings by redeploy (or queue) a new deployment or under Variables section (the latter can only be done if the environment has no running deployment).

📘

Note

• Changes to variables in a higher scope will change the variables in all inheriting scopes.
• Changes to variables for an existing environment will not take effect until the environment is redeployed. When env0 runs a deployment, it stores the variable names to be used in undeploy so changes for an Active environment will not affect the destroy process.
• If a user does not have the RUN APPLY permission (like in the Planner project role), any variable changes they make when running a plan, will only be saved to the environment if the plan is approved. If the plan is cancelled or the deployment fails - the proposed variable changes will be not be saved. For a user who does have the RUN APPLY permission, the changes are saved once the deployment is queued.

📝

Additional Content

• Managing Terraform variable hierarchy
• Why env0 is a Terraform Cloud alternative?