Error: no valid credential sources for Terraform AWS Provider found

Not specified by the original author.

TL;DR

The AWS provider found no credentials at all: no env vars, no shared config profile, no instance metadata. This fails before any API call. Set up one credential source (env vars or AWS_PROFILE), verify with aws sts get-caller-identity, then re-run.

The error

Error: error configuring Terraform AWS Provider: no valid credential sources for Terraform AWS Provider found.

Steps to fix

1. Check what the provider can see:

   aws sts get-caller-identity

   • Expected: if this fails, credentials are missing or expired outside Terraform too.

2. Provide one source. Environment variables:

   export AWS_ACCESS_KEY_ID="..."
   export AWS_SECRET_ACCESS_KEY [your value]
   export AWS_DEFAULT_REGION="us-east-1"

   or a named profile: export AWS_PROFILE="production".

   • Expected: aws sts get-caller-identity now succeeds.

3. Re-run terraform plan in the same shell (env vars do not cross shells).

   • Expected: provider configures and planning starts.

When to use this

• terraform plan/apply fails immediately with no valid credential sources, usually on a new machine, in CI without OIDC/role setup, or after keys were rotated.

When NOT to use this

• 403/AccessDenied errors mean credentials exist but lack permission: that is an IAM policy problem, not this one. SSO aws sso login expiry also presents differently.

Compatibility

• AWS provider all versions; the credential chain order (env, shared config, EC2 metadata, ECS) is stable.

Root cause

The AWS SDK checks a fixed chain of credential sources. In CI or fresh shells, none of them is populated: no env vars exported, no ~/.aws/credentials profile, no instance role. Terraform surfaces the SDK's "nothing found" as a provider configuration error.

Edge cases

• AWS_PROFILE pointing at an SSO profile needs a fresh aws sso login; the profile existing is not enough.
• In CI, prefer OIDC-to-IAM-role over long-lived keys; the error is identical when the OIDC trust is misconfigured.
• AWS_DEFAULT_REGION vs AWS_REGION: the provider reads both, but some tools only set one; set the region explicitly in the provider block to be safe.

The francesco-z/ai-agents Terraform troubleshooting skill lists this as a first-class failure signature: "Provider auth (No valid credential sources / 403) -> missing/expired env creds or wrong assumed role/backend profile. Check AWSPROFILE/GOOGLEAPPLICATIONCREDENTIALS/ARM*, backend config, and provider blocks." The d-mariano/spicyclaude troubleshooting guide gives the concrete AWS remediation: export AWSACCESSKEYID / AWSSECRETACCESSKEY / AWSDEFAULTREGION (or set AWS_PROFILE) and verify with aws sts get-caller-identity.

Not specified by the original author.

Error: pulumi:providers:aws resource 'default' has a problem: No valid credential sources found

TL;DR

The AWS provider found no credentials in any of its sources. Set up credentials the way your setup expects: environment variables, ~/.aws/credentials, aws sso login, or Pulumi ESC dynamic credentials with AWS OIDC. Then re-run pulumi preview.

The error

Diagnostics:
  pulumi:providers:aws (default):
    error: pulumi:providers:aws resource 'default' has a problem: No valid credential sources found.
    Please see https://www.pulumi.com/registry/packages/aws/installation-configuration/ for more information about providing credentials.

Fix it

1. Check what is actually configured: aws sts get-caller-identity.

   • Success check: it prints your account and ARN. If it fails, the problem is your AWS setup, not Pulumi.

2. If you use static keys, export them: set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (and AWS_SESSION_TOKEN if you have one).

   • Success check: aws sts get-caller-identity now works.

3. If you use SSO, run aws sso login (add --profile [profile] if you use a named profile) and make sure the Pulumi stack config points at that profile via aws:profile.

   • Success check: the SSO token cache refreshes and Pulumi stops reporting the error.

4. For CI or teams, prefer Pulumi ESC with AWS OIDC dynamic credentials so short-lived credentials are minted per run instead of long-lived keys.

   • Success check: pulumi preview passes in a clean environment with no static keys present.

When to use this

You hit this on pulumi preview or pulumi up with the AWS provider before any resource is created.

When NOT to use this

Do not use this for ExpiredToken or Failed to refresh cached SSO credentials. Those mean credentials existed and went stale; this one means none were found at all.

Compatibility

Pulumi CLI 3.x with the Pulumi AWS provider (v6.x). The credential chain behavior matches the underlying AWS SDK chain.

Variants

• error: pulumi:providers:aws resource 'default' has a problem: Missing region information
• error: pulumi:providers:aws resource 'default' has a problem: Invalid credentials configured.
• Error: NoCredentialProviders: no valid providers in chain

Root cause

The AWS provider walks the standard credential chain (environment, shared credentials file, SSO cache, container/EC2 metadata). In the reported case only a region was configured and no credential source existed, so provider configuration failed before any API call.

Edge cases

• A region set without credentials produces this error, not a region error. Set both.
• In Docker or CI, the SSO token cache from your laptop is not present. Use OIDC or static keys there.

Asked: how to fix Error: pulumi:providers:aws resource 'default' has a problem: No valid credential sources found. Verified answer: Fixes the Pulumi AWS provider failing at preview with no valid credential sources. The fix steps above were cross-checked against the accepted community answer at https://github.com/pulumi/pulumi-aws/pull/3310, which confirms the same resolution.

Not specified by the original author.

TL;DR

Provider credentials via env vars set in the CI job from the CI secret store. No credential arguments in provider blocks, ever. TF\CLI\CONFIG\_FILE points at a CLI config file for installation methods (network mirrors) and provider installation settings. One CI job with one credential set per environment; never reuse prod credentials for a dev plan.

When to use

You are seeing this: No credential arguments in provider blocks, ever. Use this skill when you run into "Terraform provider credentials in CI: env vars, never committed secrets".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

How

1. Provider credentials via env vars set in the CI job from the CI secret store. No credential arguments in provider blocks, ever.
2. Backend credentials the same way: partial backend config in the repo, secrets via env vars at init.
3. TF_CLI_CONFIG_FILE points at a CLI config file for installation methods (network mirrors) and provider installation settings. It is config, not secrets, and can be committed.
4. TF_IN_AUTOMATION=1 tells Terraform it runs unattended: cleaner output, no interactive prompts. Set it in every CI job.

Why

Provider blocks accept credentials as arguments, which means `accesskey [your value] ends up in git, in plan files, and in state. Every provider also reads standard env vars (AWSACCESSKEYID, GOOGLECREDENTIALS, ARMCLIENT_SECRET, and so on). Env vars keep secrets out of every artifact Terraform produces.

Rules for agents

1. If you see a literal secret in a .tf file, tfvars, or backend config, stop and rotate it. It is already compromised; removing it from the file is not enough.
2. terraform plan output can echo sensitive values. Mark variables sensitive = true and treat plan logs as secret-bearing.
3. Short-lived credentials (OIDC / workload identity) beat long-lived keys. Prefer the CI provider's OIDC federation over static keys when the backend supports it.
4. Different environments need different credentials. One CI job with one credential set per environment; never reuse prod credentials for a dev plan.

Providers read credentials from environment variables; TFCLICONFIGFILE sets the CLI config file location; TFIN_AUTOMATION adjusts output for automation. Verified against live CLI/config docs 2026-09-26. Verified against live docs 2026-09-26.