Terraform Cloud is HashiCorp’s managed service offering that eliminates the heavy lifting for practitioners, teams, and organizations to use Terraform in production. When using Terraform Cloud to manage AWS infrastructure, authentication to the AWS provider determines how credentials are obtained, stored, and rotated for each run. Traditional approaches rely on static credentials stored as workspace variables or variable sets. The newer dynamic provider credentials feature offers the ability to generate dynamic, short-lived credentials for Terraform Cloud runs using OpenID Connect protocol (OIDC). This feature is now available for all Terraform Cloud tiers.
HashiCorp is an AWS Partner and cloud infrastructure automation company that provides the open-source tools Terraform, Vagrant, Packer, Vault, Consul, and Nomad. Enterprise versions of these products enhance the open-source tools with features that promote collaboration, operations, governance, and multi-data center functionality.
Static Credentials and Operational Risks
Terraform users typically use static credentials to authenticate with AWS providers, but this practice brings operational and security challenges. Users store the static credentials by using workspace variables or variable sets, adding additional steps in their Terraform workflow. Storing long-lived credentials could expose a security risk, even if you rotate your AWS credentials regularly.
When authenticating to AWS, we recommend you use an AWS Identity and Access Management (IAM) role to grant temporary security credentials, which are time-bound, last from a few minutes to several hours, and do not require you to rotate them or explicitly revoke them when they’re no longer needed or expire.
Temporary security credentials are generated dynamically and provided to the user when they assume the IAM role. You can assume the IAM role using an IAM identity such as IAM user or an external identity provider (IdP). For example, you can federate identity using an OIDC-compatible IdP such as Terraform Cloud.
Terraform needs credentials to create resources on your cloud provider. This page covers how to set up credentials for AWS (primary throughout this tutorial), plus GCP and Azure for reference.
Warning: Never hardcode credentials in .tf files. Use environment variables, credential files, or IAM roles instead.
How Dynamic Provider Credentials Work
HCP Terraform's dynamic provider credentials let you establish a trust relationship between HCP Terraform and your cloud provider. They limit the blast radius of compromised credentials by using unique, short-lived credentials for each Terraform run. Dynamic credentials also give you fine-grained control over the resources that each of your HCP Terraform projects and workspaces can manage. HCP Terraform supports dynamic credentials for AWS, Google Cloud Platform, Azure, and Vault.
When you use dynamic credentials, HCP Terraform begins each run by authenticating with your cloud provider, passing it details about the workload, including your organization and workspace name. Your cloud provider then responds with temporary credentials which HCP Terraform uses to provision your resources for the run. This workflow is based on the OpenID Connect protocol (OIDC), an open source standard for verifying identity across different systems.
In this tutorial, you will set up a trust relationship between HCP Terraform and your cloud provider, and configure a workspace with dynamic credentials. Then you will use dynamic credentials to provision infrastructure for that workspace.
If you use Vault to manage your secrets, you can also use it to manage your dynamic provider credentials. Refer to the Authenticate Providers with Vault-Backed Dynamic Credentials tutorial for details.
This tutorial assumes that you are familiar with the Terraform and HCP Terraform workflows.
The workflow for AWS is:
- Terraform Cloud sends the identity token to AWS Security Token Service (AWS STS), which verifies the token using Terraform Cloud’s public signing key to ensure the token is genuine and the information in it can be trusted.
- If the token is genuine, AWS STS returns the IAM role temporary credentials that will be used by the Terraform AWS provider, and the plan or apply can proceed.
Configuring Trust Relationship with AWS IAM
To start using dynamic provider credentials, users must first configure a trust relationship between AWS IAM with Terraform Cloud as the IdP. This is done by creating an IAM OIDC identity provider on AWS IAM.
Users provide configuration such as the Provider URL (https://app.terraform.io) and the Audience (aws.workload.identity). Below is the example of configuration for Terraform Cloud as IdP.
After creating the IAM OIDC identity provider, users must create one or more IAM roles.
The new dynamic provider credentials feature offers the ability to generate dynamic, short-lived credentials for Terraform Cloud runs using OpenID Connect protocol (OIDC). This feature is now available for all Terraform Cloud tiers.
Optional Configuration
Terraform Cloud provides optional configuration to further customize the dynamic provider credentials. The tables below lists the optional environment variables.
| Variable | Purpose |
| TFCAWSWORKLOADIDENTITYAUDIENCE | Will be used for the aud claim of the identity token. Default is aws.workload.identity |
| TFCAWSPLANROLEARN | IAM role to use for the plan phase |
| TFCAWSAPPLYROLEARN | IAM role to use for the apply phase |
Using this optional configuration, users can create two distinct IAM roles for the plan and apply phases. For example, TFCAWSPLANROLEARN will have read-only access to all AWS resources, while TFCAWSAPPLYROLEARN will have write access to the relevant AWS resources.
Environment Variable Authentication Methods
Each cloud provider has its own set of expected environment variable names.
AWS Authentication
The AWS provider reads credentials from the standard AWS environment variables.
Basic Access Key Authentication
bash
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_DEFAULT_REGION="us-east-1"
With these variables set, your Terraform configuration does not need any credential parameters:
hcl
provider "aws" {
region = "us-east-1"
}
resource "aws_s3_bucket" "example" {
bucket = "my-terraform-bucket"
}
Session Token (for Temporary Credentials)
If you are using temporary credentials from AWS STS (common with MFA or assumed roles):
bash
export AWS_ACCESS_KEY_ID="ASIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="FwoGZXIvYXdzEBYaDHW...long-token-string..."
export AWS_DEFAULT_REGION="us-east-1"
Using AWS Profiles
Instead of raw credentials, you can point Terraform at an AWS CLI profile:
bash
export AWS_PROFILE="production"
export AWS_DEFAULT_REGION="us-east-1"
This reads credentials from the shared AWS config and credentials files under the specified profile name.
Assuming a Role
bash
export AWS_PROFILE="production"
export
AWS is the primary cloud provider used in this tutorial’s examples.
Credential Priority
Terraform (via the AWS provider) checks credentials in this order:
- Provider block arguments (not recommended — hardcoded)
- Environment variables (AWSACCESSKEYID, AWSSECRETACCESSKEY)
- Shared credentials file (~/.aws/credentials)
- EC2 Instance Metadata / ECS Task Role
- AWS SSO credentials
No keys to manage, no keys to leak.
GCP and Azure Reference
For Google Cloud Platform, the most common method during development:
bash
gcloud auth application-default login
This opens a browser for OAuth login and creates a local credentials file that Terraform reads automatically.
For CI/CD, use a service account key:
bash
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account-key.json"
For Microsoft Azure, the quickest way to authenticate:
bash
az login
This opens a browser for authentication.
Provider Block and Workspace Configuration
Terraform Cloud is HashiCorp’s managed service offering and eliminates the heavy lifting for practitioners, teams, and organizations to use Terraform in production.
With dynamic provider credentials, the provider block does not require static keys. The authentication is handled by Terraform Cloud at run time via OIDC token exchange with AWS STS.
The benefits of the dynamic approach are:
- No keys to manage, no keys to leak.
- Short-lived credentials per run.
- Fine-grained control over resources per project and workspace.
- Separation of plan and apply permissions via distinct IAM roles.
HashiCorp is an AWS Partner and cloud infrastructure automation company that provides the open-source tools Terraform, Vagrant, Packer, Vault, Consul, and Nomad.
Conclusion
Moving from static AWS credentials stored in workspace variables to dynamic provider credentials via OIDC fundamentally changes the security posture of Terraform Cloud workflows on AWS. Static credentials add operational steps and create long-lived secrets that can be exposed even with regular rotation. Dynamic, short-lived credentials generated per run via a trust relationship between Terraform Cloud and AWS IAM eliminate key management and limit blast radius.
The dynamic provider credentials feature is now available for all Terraform Cloud tiers and uses OpenID Connect to exchange an identity token for temporary IAM role credentials from AWS STS. Configuration starts with creating an IAM OIDC identity provider for Terraform Cloud with Provider URL https://app.terraform.io and Audience aws.workload.identity, then creating IAM roles with appropriate trust policies. Optional environment variables TFCAWSWORKLOADIDENTITYAUDIENCE, TFCAWSPLANROLEARN, and TFCAWSAPPLYROLEARN allow further customization, including separate read-only plan roles and write apply roles.
For environments that still rely on environment variables, the AWS provider reads credentials from standard variables AWSACCESSKEYID, AWSSECRETACCESSKEY, AWSSESSIONTOKEN, and AWSDEFAULTREGION, or from AWS_PROFILE referencing shared config files. Credential resolution follows a defined priority from provider block arguments through environment variables, shared files, EC2 metadata, and AWS SSO.
Together, these patterns provide a secure, auditable, and least-privilege path to authenticate Terraform Cloud to AWS without long-lived secrets.