> 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/3.0/platform/iacm-connectors-variables/aws-connector-auth.md).

# AWS Connector Authentication

When defining authentication to AWS for Harness Infrastructure as Code there are several methods for doing so. Harness connectors act as a way to centrally define an authentication pattern which can then be utilized across many workspaces. Depending on the build infrastructure type you are using for your executions there are different methods that are supported.

{% hint style="info" %}
**AWS SESSION DURATION**

To increase the default session duration in IaCM steps, you can set `PLUGIN_AWS_SESSION_DURATION` as a stage variable to a custom limit (default: `15m`).
{% endhint %}

### Cloud <a href="#cloud" id="cloud"></a>

Harness offers a [hosted execution environment](/continuous-integration/troubleshooting-and-resources/ci-articles-and-faqs/harness-cloud-faqs.md) where your builds run on independent ephemeral machines. Using this environment requires that all the endpoints you are configuring using TF are exposed to the public internet.

If you are using this environment, you can use Access Keys or OIDC in a Harness AWS connector to connect. It is recommended that you use OIDC over access keys as keys have to be rotated whereas OIDC uses a trust between Harness and your AWS account to do "serverless" authentication.

### Kubernetes (self-hosted) <a href="#kubernetes-self-hosted" id="kubernetes-self-hosted"></a>

The other option for executing IaCM pipelines is to use a Kubernetes environment to launch a pod that will execute the steps defined in your pipeline. This requires a cluster, delegate, and if the delegate is not installed into the target cluster, a service account token. Go to [Kubernetes cluster connector settings reference](/harness-ai/use-harness-platform/connectors/cloud-providers/ref-cloud-providers/kubernetes-cluster-connector-settings-reference.md) to configure the connector.

#### "Serverless" Auth <a href="#serverless-auth" id="serverless-auth"></a>

If you are using this environment, you can still use Access Keys or OIDC in a Harness AWS connector to connect. It is recommended that you use OIDC over access keys as keys have to be rotated whereas OIDC uses a trust between Harness and your AWS account to do "serverless" authentication.

#### Execution Environment Auth <a href="#execution-environment-auth" id="execution-environment-auth"></a>

In addition, you can also use authentication inherited from the execution environment, which is normally an EKS cluster.

**Node Role**

The first option is to use the "node role" or the instance profile of the Kubernetes node that the execution pod runs on as the identity of the TF being ran. To do this you would create a Harness AWS connector that LEVERAGES the "IAM Role on Delegate" option.

![IAM Role on Delegate selected](/files/BccYjMda9waOaDt0Br04)

You will have to select some delegate for the connector to be tied to. This selection does not matter as it will be ignored when used in an IaCM workspace. Select a delegate and save the connector. The healthcheck for this connector may fail if the delegate selected does not have an AWS instance profile associated with it, so it may be helpful to select a delegate that does.

This does not require EKS to be used as the cluster type and could be ran on any self-hosted cluster using EC2 instances for the nodes, when there are instance profiles used.

Go to [Using STS AssumeRole](#using-sts-assumerole) to use a second role in the connector.

**IRSA**

The second option uses an IRSA configuration on the build pod to assume an IAM role. To use this authentication method, set up an OIDC provider for your cluster and a role. Go to [IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) to configure both.

Next, create a Harness AWS Connector that uses the "IRSA" method. You will have to select some delegate for the connector to be tied to. This selection does not matter as it will be ignored when used in an IaCM workspace. Select a delegate and save the connector. The healthcheck for this connector may fail if the delegate selected does not have an AWS instance profile associated with it, so it may be helpful to select a delegate that does.

![IRSA selected](/files/ZtputfH3MOpVebPTDep6)

You will now need to create a Kubernetes service account in the namespace to be used for your executions.

```shell
kubectl -n <namespace> create sa <sa name>
kubectl annotate sa <sa name> -n <namespace> eks.amazonaws.com/role-arn=<irsa role arn>
```

Finally, in your IaCM stage you will need to add the namespace and service account you created to be used in your build pod. This is set under Infrastructure > Platform and Advanced.

![SAAnnotations](/files/tkqosGUcOXCdZjUlKW6V)

Go to [Using STS AssumeRole](#using-sts-assumerole) to use a second role in the connector.

**Using STS AssumeRole**

Both the NodePool and IRSA authentication styles allow you to specify a separate role in the connector to use for the IaCM steps. The role specified here will be used by the IaCM stage during execution.

When the stage executes, the steps will call the STS `AssumeRole` service to assume the second IAM role defined in the connector, and that is the role that will be used when running the IaCM steps. This role can be in a separate AWS account, allowing the IaCM stage running in centralized infrastructure to reach any number of target accounts.

![Connector with STS AssumeRole](/files/eWNPAWHuvX3OmQ7dMhZK)

### IaCM plugin environment variables (PLUGIN\_ prefix) <a href="#iacm-plugin-environment-variables-plugin-prefix" id="iacm-plugin-environment-variables-plugin-prefix"></a>

IaCM plugin steps run inside a containerized environment that uses a `PLUGIN_` prefix convention for environment variables. Standard AWS environment variables (like `AWS_REGION`) are not recognized by the IaCM plugin. You must use the `PLUGIN_` prefixed versions instead.

{% hint style="warning" %}
**USE PLUGIN\_ PREFIXED VARIABLES INSTEAD OF STANDARD AWS VARIABLES**

Standard AWS environment variables like `AWS_REGION` or `AWS_DEFAULT_REGION` do not apply in the IaCM plugin context. If your Terraform operations target the wrong AWS region or fail with STS endpoint errors, confirm that you are setting `PLUGIN_AWS_REGION` rather than `AWS_REGION`.
{% endhint %}

#### Commonly used PLUGIN\_ variables <a href="#commonly-used-plugin-variables" id="commonly-used-plugin-variables"></a>

Set these as **stage variables** or **step environment variables** in your IaCM pipeline:

| Variable                      | Description                                                             | Example value            |
| ----------------------------- | ----------------------------------------------------------------------- | ------------------------ |
| `PLUGIN_AWS_REGION`           | AWS region for STS regional endpoint routing and provider configuration | `us-west-2`              |
| `PLUGIN_AWS_SESSION_DURATION` | Duration for AWS session tokens (default: `15m`)                        | `30m`                    |
| `PLUGIN_CONNECTOR_REF`        | Override the connector reference at the step level                      | `account.myAwsConnector` |
| `PLUGIN_TF_VERSION`           | Override the Terraform version for the step                             | `1.5.7`                  |

#### Example: set PLUGIN\_AWS\_REGION as a stage variable <a href="#example-set-pluginawsregion-as-a-stage-variable" id="example-set-pluginawsregion-as-a-stage-variable"></a>

```yaml
stage:
  variables:
    - name: PLUGIN_AWS_REGION
      type: String
      value: us-west-2
```

This ensures the IaCM plugin uses the correct regional STS endpoint when assuming roles or making AWS API calls.