Terraform provider credentials in CI: env vars, never committed secrets

Terraform provider credentials in CI: env vars, never committed secrets

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.

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.

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.