> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/infrastructure-as-code-management/platform/iacm-connectors-variables/connectors-variables.md).

# Connectors & Variable Sources

**Connectors and Variables** define the full set of inputs and integrations your workspace uses when running **Plan**, **Apply**, or **Drift detection** pipelines. These inputs can come from multiple sources and are resolved based on a clear order of precedence.

### Connectors <a href="#connectors" id="connectors"></a>

A **connector** is required to authenticate with cloud providers or external systems. Most workspace operations, like fetching modules or variable files, depend on a connector.

:::info Supported connectors IaCM supports the following cloud providers and external systems through connectors:

* **AWS**: Amazon Web Services integration
* **GCP**: Google Cloud Platform integration
* **Azure**: Microsoft Azure integration
* **Vault**: HashiCorp Vault integration for secrets management

Go to [Supported integrations for IaCM](/infrastructure-as-code-management/troubleshooting-and-resources/whats-supported.md) to review detailed configuration information.

{% hint style="info" %}
**ADD CONNECTORS**

Connectors can be added via Account Settings or directly from your workspaces **Connectors and Variables** tab.
{% endhint %}

#### Add a connector <a href="#add-a-connector" id="add-a-connector"></a>

To add a connector, follow these steps:

1. From your workspace **Connectors and Variables** tab, click **+ Connector**.
2. Select an existing connector from your account or project scope, for example, `aws-oidc`.

Or, you can add a new connector by clicking **+ New Connector**.

{% hint style="info" %}
**INTERACTIVE GUIDE**

Go to [Add connectors](/infrastructure-as-code-management/new-to-iacm/get-started.md#add-connectors) for an interactive guide.
{% endhint %}

#### Connectors from templates <a href="#connectors-from-templates" id="connectors-from-templates"></a>

If your workspace is created from a workspace template, it may include connectors defined in the template.

* These appear in the **Connectors and Variables** tab.
* Currently, these connectors **cannot be modified** in the workspace.

#### Multiple connectors <a href="#multiple-connectors" id="multiple-connectors"></a>

You can attach more than one connector to a workspace. This allows your IaCM runs to access multiple cloud providers or external systems from a single workspace (for example, both AWS and Azure). However, a workspace can only have one connector per provider type (for example, one AWS, one GCP, one Azure).

* Connectors appear in the **Connectors and Variables** tab.
* If a workspace is linked to a template, template-defined connectors are included automatically and can be locked. Go to [Locked fields](/infrastructure-as-code-management/platform/workspaces/workspace-templates.md#locked-fields) to understand which template settings are enforced.
* You can add more connectors inline or select from account/project scope.

***

### Secrets management <a href="#secrets-management" id="secrets-management"></a>

The **Vault** connector provides HashiCorp Vault integration for secrets management in IaCM workspaces.

**Key features:**

* **Workspace-level attachment**: Vault connectors are attached at the workspace level.
* **Authentication methods**: Currently supports **Token** and **JWT** authentication.
* **Flexible configuration**: Can be added to workspaces after creation or through variable sets.
* **Runtime injection**: Secrets are automatically injected into runtime environments as environment variables.
* **Provider initialization**: Harness automatically adds environment variables based on the selected authentication type, which you must consume to initialize the Vault provider in your OpenTofu/Terraform code.

***

### Variable sources <a href="#variable-sources" id="variable-sources"></a>

{% hint style="info" %}
**SET VARIABLES**

You can provide variables in the following ways:

* **Variable Sets:** Reusable collections of variables and secrets defined at the account level and applied to multiple workspaces.
* **Workspace Templates:** Predefined templates that inject connectors and variables into workspaces.
* **Workspace-level variables:** Environment variables and OpenTofu/Terraform variables defined directly in the workspace.
* **Variable files:** `.tfvars`, `.json`, or `.yaml` files stored in Git and linked to the workspace.
* **Connectors:** Authentication references for cloud providers, Git, and external systems (used for fetching modules, variable files, or credentials).
* **HCL defaults:** Default values defined directly in your OpenTofu/Terraform code.
* **Pipeline-level variables:** Values passed at runtime from pipelines.
  {% endhint %}

#### Order of precedence <a href="#order-of-precedence" id="order-of-precedence"></a>

Variables can be defined in multiple places. The order of precedence determines which value is used if the same variable appears more than once.

\| Priority | Source | |----------------|------------------------------------------------------------------------| | 1 (highest) | Workspace Template variables | | 2 | Workspace-level variables (Environment or OpenTofu/Terraform variables)| | 3 | Variable Sets (in their assigned priority order) | | 4 (lowest) | HCL default values in your code |

**If a variable is defined in multiple places, Harness resolves conflicts using this order of precedence.**

***

### Environment variables <a href="#environment-variables" id="environment-variables"></a>

Environment variables provide runtime configuration for your infrastructure. These behave like standard shell variables and can be used by your provisioning logic, module behavior, or CLI tooling.

* **Key**: The name of the variable (for example, `TF_LOG` or `ENVIRONMENT`).
* **Value**: You can set a static value, insert a pipeline variable (FQN), or use **`<+input>`** for runtime input.

#### Add an environment variable <a href="#add-an-environment-variable" id="add-an-environment-variable"></a>

To add an environment variable, follow these steps:

1. Click **+ New Environment Variable**.
2. Define the `Type` (usually `string`).
3. Provide a `Key` and a `Value`.

```yaml
# Example: Static and runtime-injected environment variables <a href="#example-static-and-runtime-injected-environment-variables" id="example-static-and-runtime-injected-environment-variables"></a>
environmentVariables:
  - key: TF_LOG
    value: INFO
    type: String
    source: CUSTOM
  - key: ENVIRONMENT
    value: <+input>
    type: String
    source: CUSTOM
```

***

### OpenTofu/Terraform variables <a href="#opentofuterraform-variables" id="opentofuterraform-variables"></a>

OpenTofu/Terraform variables (`variable {}` blocks in your code) must be declared by name and value. These are injected into Terraform runs and used in your `*.tf` files.

1. Click **+ Add Variable** under the **OpenTofu/Terraform Variables** section.
2. Define the `Key` to match your Terraform variable name.
3. Set the `Value`, or use **`<+input>`** for runtime prompts.

***

Each variable declared in your OpenTofu/Terraform code must be supplied with a value from one of the following input sources, listed from lowest to highest precedence. Go to [Order of precedence](#order-of-precedence) for the full list of variable options.

#### Option 1: define default values in HCL <a href="#option-1-define-default-values-in-hcl" id="option-1-define-default-values-in-hcl"></a>

You can assign a default value directly in your OpenTofu/Terraform code. This acts as a fallback if no value is provided from the workspace or pipeline.

```hcl
# main.tf <a href="#maintf" id="maintf"></a>
variable "instance_type" {
  type    = string
  default = "t3.micro"
}
```

#### Option 2: provide values in the workspace <a href="#option-2-provide-values-in-the-workspace" id="option-2-provide-values-in-the-workspace"></a>

Configure variables in the OpenTofu/Terraform Variables section of your workspace. These values override any defaults in your code.

```yaml
# Workspace configuration <a href="#workspace-configuration" id="workspace-configuration"></a>
terraformVariables:
  - key: instance_type
    value: <+input> # or a static value like "t3.large"
    type: String
    source: CUSTOM
```

{% hint style="info" %}
**RUNTIME INPUT**

Use `<+input>` to prompt users for values at runtime.
{% endhint %}

***

### Variable files <a href="#variable-files" id="variable-files"></a>

Variable files allow you to inject multiple variables via `.tfvars`, `.json`, or `.yaml` files stored in Git.

#### Add a variable file <a href="#add-a-variable-file" id="add-a-variable-file"></a>

To add a variable file, follow these steps:

1. Click **+ New Variable File**.
2. Select the **Connector** to access your Git repo.
3. Choose a repository, branch, and file path (for example, `main` or `envs/dev.tfvars`).

{% hint style="info" %}
Harness will retrieve and use this file during your pipeline execution. You can include multiple files if needed.
{% endhint %}

```yaml
# Workspace variable file definition <a href="#workspace-variable-file-definition" id="workspace-variable-file-definition"></a>
variableFiles:
  - type: Git
    spec:
      connectorRef: account.git_connector
      repoName: terraform-configs
      branch: main
      paths:
        - envs/dev.tfvars
```

{% hint style="info" %}
**VARIABLE FILE SOURCE**

Your variable files and HCL can come from the same Git repository or different repositories.
{% endhint %}

***

### Variable sets <a href="#variable-sets" id="variable-sets"></a>

A Variable Set is a reusable collection of environment variables, OpenTofu/Terraform variables, and secrets. They allow you to standardize configuration across multiple workspaces.

Variable Sets are supported at the account, org, and project level:

* Navigate to **Account Settings** > **IaCM Settings** > **Variable Sets**.
* **Create:** Click **Create a new Variable Set**.
* **Update:** Click an existing Variable Set tile.
* **Delete:** Use the ellipsis menu on a Variable Set tile and select **Delete**.

When applied to a workspace, Variable Sets can be prioritized. Variables from a higher-priority set will override those from lower-priority sets.

#### Referenced by tab <a href="#referenced-by-tab" id="referenced-by-tab"></a>

When viewing a Variable Set, you can use the **Referenced By** tab to see all workspaces where the variable set is being used. This helps you identify the downstream impact when making changes to a variable set, ensuring you understand which workspaces might be affected by any modifications.

{% hint style="info" %}
**VARIABLE SET PRIORITY**

When multiple Variable Sets are applied to a workspace, you can control their priority to determine which values take precedence when conflicts occur:

1. In the Connectors and Variables tab of a workspace, you can view all attached Variable Sets.
2. Variable Sets can be reordered using drag-and-drop functionality to change their priority.
3. The system will clearly indicate when variables conflict between sets, showing which one takes precedence.
4. Priority order is: Priority 1 > Priority 2 > Priority 3, etc.
   {% endhint %}

When variables with the same name exist in multiple Variable Sets, the value from the highest priority set will be used. The interface will show which Variable Set is providing the value that will actually be used during execution.

***

### Input sources and runtime behavior <a href="#input-sources-and-runtime-behavior" id="input-sources-and-runtime-behavior"></a>

Each variable shows its **source**, such as:

* `TEMPLATE`: inherited from the selected Template.
* `CUSTOM`: defined directly in the workspace.

You can use **`<+input>`** to prompt users to supply values at runtime.

***

### Next steps <a href="#next-steps" id="next-steps"></a>

Go to the following pages to continue configuring your workspace:

* [Provision your workspace](/infrastructure-as-code-management/platform/workspaces/provision-workspace.md) using the configured inputs.
* [Add OPA policies](/infrastructure-as-code-management/platform/policy-and-governance/opa-workspace.md) to enforce policy compliance.