Terraform is an Infrastructure as Code tool created by HashiCorp that allows users to define and manage infrastructure resources in a declarative way. When using Terraform to provision resources in AWS, it is essential to configure your CLI for seamless and secure interaction with AWS APIs. Authentication is a cornerstone of securely managing infrastructure in the cloud. AWS offers multiple ways to authenticate your Terraform CLI and the choice of method directly impacts security, portability, and operational overhead.
Every Terraform AWS project starts the same way - configuring the provider to authenticate with your AWS account. Get it wrong and nothing works. Get it right but insecurely and you've got credentials leaking everywhere. Understanding the credential resolution chain, provider options, and practical authentication patterns is critical for both local development and production use.
Credential Resolution and Provider Basics
At its most basic, the AWS provider just needs a region.
hcl
provider "aws" {
region = "us-east-1"
}
But where do the credentials come from? Terraform follows a credential resolution chain, similar to the AWS CLI.
Configuration for the AWS Provider can be derived from several sources, which are applied in the following order:
- Parameters in the provider configuration
- Environment variables
- Shared credentials and configuration files
- Container credentials
- Instance profile credentials and region
- External credentials process
The most important Terraform AWS provider options include:
- region – specify the AWS region in which we want to create your resources
- access_key – the AWS access key we use for authenticating to the provider
- secret_key – the AWS secret key associated with our access key
- assume_role – configuration block for specifying what role we want to use to authenticate with AWS
- token – session token for temporary credentials
You can look here for all the options you can configure for your AWS provider.
Environment Variables Authentication
The most straightforward way to authenticate Terraform with AWS is by setting environment variables. Terraform reads the following environment variables to authenticate with AWS:
- AWSACCESSKEY_ID: Your AWS access key ID.
- AWSSECRETACCESS_KEY: Your AWS secret access key.
- AWSSESSIONTOKEN (optional): Token for temporary credentials when assuming a role.
Example:
bash
export AWS_ACCESS_KEY_ID="your-access-key-id"
export AWS_SECRET_ACCESS_KEY="your-secret-access-key"
export AWS_SESSION_TOKEN="your-session-token"
Environment variables are widely used in CI/CD pipelines and local development for their simplicity, but managing credentials securely can be challenging.
Named Profiles Authentication
AWS CLI allows you to manage multiple sets of credentials using named profiles in the ~/.aws/credentials file.
The usual and recommended way to authenticate to AWS when using Terraform is via the AWS CLI, rather than any of the provider options listed above. To do this, first, install the AWS CLI, then type aws configure.
You can then enter your access key ID, secret access key, and default region.
For local development, environment variables or named profiles are simple and effective. Named profiles help separate credentials per account, role, or environment without modifying code.
AWS Single Sign-On Authentication
AWS Single Sign-On (SSO) is a modern authentication method that allows users to authenticate without directly managing IAM keys.
To use AWS SSO with Terraform:
Configure SSO using the AWS CLI:
bash
aws configure sso
Export the SSO profile:
bash
export AWS_PROFILE="sso-profile"
Use Terraform with the SSO profile.
AWS SSO ensures that credentials are short-lived and minimizes the risk of unauthorized access.
For production, using IAM roles or AWS SSO is more secure.
Credentials Helper Plugins
Terraform supports external credentials helper plugins for advanced use cases. For instance, if your organization uses tools like HashiCorp Vault, you can configure Terraform to fetch AWS credentials dynamically.
Example:
hcl
provider "aws" {
region = "us-west-2"
credentials = {
plugin = "custom-plugin"
}
}
This method is powerful for organizations with complex security policies.
AWS CloudShell Authentication
AWS CloudShell provides a pre-configured environment with AWS CLI credentials already authenticated. Running Terraform from AWS CloudShell eliminates the need for additional authentication configurations.
How to Use:
- Open AWS CloudShell in your AWS Management Console.
- Install Terraform (if not already installed).
- Run Terraform commands using the pre-configured AWS credentials.
This approach is convenient for quick, ad-hoc tasks.
Provider Configuration Parameters
There are many ways to authenticate using the Terraform AWS provider.
- Parameters in the provider configuration
To specify parameters in the AWS provider configuration, we can set an access key and secret key as follows:
hcl
provider "aws" {
region = "us-west-2"
access_key = "my-access-key"
secret_key = "my-secret-key"
}
Note: This is NOT recommended! If your secrets are hardcoded into your configuration files and committed to source control, they may be compromised.
Similarly, we can specify a session access token, typically provided after a successful identity federation or Multi-Factor Authentication (MFA) login.
Before we can authenticate, we will need to create an access key for use with Terraform. To do so, browse to the IAM section in the AWS console and click 'create new access key.'
Authentication Methods Comparison
The following table summarizes key characteristics for selection.
| Method | Credential Source | Typical Use Case | Security Notes |
|---|---|---|---|
| Environment Variables | AWSACCESSKEYID, AWSSECRETACCESSKEY, AWSSESSIONTOKEN | CI/CD pipelines and local development | Simple but requires secure secret handling |
| Named Profiles | ~/.aws/credentials file | Local development with multiple accounts | Centralized profile management via AWS CLI |
| AWS SSO | aws configure sso and AWS_PROFILE | Enterprise users without static keys | Short-lived credentials, minimal risk |
| Credentials Helper Plugins | External plugin via provider block | Organizations with Vault or custom secret management | Dynamic credential fetching |
| AWS CloudShell | Pre-configured AWS CLI credentials | Quick ad-hoc tasks in console | No additional configuration needed |
| Provider Parameters | accesskey, secretkey, token in HCL | Testing only | Not recommended for committed code |
Best Practices for Secure Authentication
Each AWS authentication method has its strengths and is suited for different scenarios.
Best Practices
- Use Short-Lived Credentials: Prefer temporary credentials (e.g., IAM roles, SSO) over static keys.
- Secure Static Keys: If you must use static keys, rotate them regularly and store them securely (e.g., in AWS Secrets Manager).
- Leverage Automation: Use CI/CD tools or automation platforms to manage credentials securely.
- Monitor and Audit: Enable CloudTrail and AWS Config to monitor API activity and resource configurations.
The article is a step-by-step guide on how to install terraform and use it to configure AWS infrastructure from local command prompt. More specifically, we will learn how to authenticate terraform with AWS and how to create an S3 bucket using terraform code. Along the way, we learn how to download AWS credentials, access key ID and secret, as well as why we have to attach permission policies to allow users to make configuration changes.
Target Audience considerations include aspiring platform engineers who have an existing AWS account and data professionals who want to learn Infrastructure-as-Code but do not know where to start.
Conclusion
Terraform AWS authentication is not a single setting but a set of complementary patterns that trade off convenience against security posture. Environment variables and named profiles provide the fastest path to getting started locally, while AWS SSO and IAM roles provide the short-lived, auditable credentials appropriate for production workloads. Provider-level parameters offer explicit control but should be avoided for secrets that might be committed to source control.
The credential resolution chain means Terraform will gracefully fall back from explicit provider parameters through environment variables, shared files, container credentials, instance profiles, and external processes. Designing your workflow around this chain allows teams to develop locally with named profiles and promote the same Terraform code to CI/CD where environment variables or external credential processes supply temporary credentials.
Security hygiene remains the deciding factor. Short-lived credentials, regular rotation of static keys, secure storage of secrets, automation of credential provisioning, and continuous monitoring via CloudTrail and AWS Config together reduce the risk of credential leakage. By understanding these options, you can choose the most secure and convenient way to authenticate your Terraform CLI for AWS.