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

## Why

Provider blocks accept credentials as arguments, which means `access_key [your value] ends up in git, in plan files, and in state. Every provider also reads standard env vars (AWS_ACCESS_KEY_ID, GOOGLE_CREDENTIALS, ARM_CLIENT_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.