Authentication and Credentials

How Terraform authenticates to AWS decides two things at once: whether an apply works, and how much damage a leaked secret can do. The AWS provider uses the standard credential chain — environment variables, shared profiles, instance roles, and in CI an OIDC-assumed role — so you rarely configure credentials in Terraform at all; you arrange for the chain to find them.

There is one rule that overrides everything else on this page: never put long-lived access keys in your Terraform code, your tfvars, or anything that reaches version control. A committed key pair is a permanent credential in a public history, and rotating it is the easy part — finding everywhere it leaked to is not.

The AWS Credential Chain

The provider resolves credentials in a fixed order and uses the first source it finds. Static keys set directly in the provider block come first of all — which is exactly why you leave them out — so in practice the chain runs: environment variables (AWS_ACCESS_KEY_ID, AWS_PROFILE), then a named profile in ~/.aws/credentials, then a container (ECS) or EC2 instance role attached to the compute Terraform runs on. Because the chain is ordered, a stray AWS_ACCESS_KEY_ID in your shell quietly wins over the profile you meant to use — the most common "why is this applying to the wrong account?" surprise.

Local Development Auth

For local work, authenticate with a named profile rather than keys pasted into a block. The best version of this is an SSO-backed profile that mints short-lived credentials, so even a machine that gets compromised holds nothing permanent. You select it with AWS_PROFILE and Terraform's provider picks it up through the chain — no access_key anywhere in the config.

# Run `aws sso login --profile dev` to refresh credentials
[profile dev]
sso_session    = corp
sso_account_id = 111122223333
sso_role_name  = Developer
region         = us-east-1

With that profile present, the provider needs nothing but a region. The credentials come from the chain, scoped and short-lived, and rotate themselves each login.

provider "aws" {
  region = "us-east-1"
  # export AWS_PROFILE=dev before running terraform
}

CI/CD Auth With OIDC

In CI, the right pattern is OIDC, not stored keys. GitHub Actions or GitLab presents a signed identity token to AWS STS, which exchanges it for short-lived credentials of an IAM role — no access key is ever stored as a CI secret. The pipeline configures AWS once, and Terraform's provider reads the resulting environment credentials through the chain. This removes the single highest-value secret a CI system would otherwise hold.

permissions:
  id-token: write   # required for the OIDC token
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::111122223333:role/GhaTerraform
      aws-region:     us-east-1
  - run: terraform apply -auto-approve

assume_role and MFA

Role assumption is the same mechanism whether it backs a cross-account provider or an elevated local session. An assume_role block on the provider trades the chain's base credentials for a role's temporary credentials, and it can require MFA before granting them — the way a human reaches a privileged production role for a one-off apply. The base identity stays low-privilege; the elevated access is short-lived and gated.

provider "aws" {
  region = "us-east-1"

  assume_role {
    role_arn     = "arn:aws:iam::111122223333:role/ProdDeployer"
    session_name = "prod-deploy"
  }
}

What Never to Do

The anti-patterns are all variations of one thing: a long-lived secret somewhere it can leak. Static keys hardcoded in a provider block. Keys in a .tfvars file that later gets committed. Keys in a committed .env. A secret in an output, printed into a CI log that is retained and searchable. And the subtle one — credentials marked sensitive that still land in state in plaintext. None of these are protected by the chain; the chain only helps when you let it supply the credentials instead of embedding them.