Authentication and Provider Debugging

Scenario: A plan works locally using an administrator's cached credentials but fails in CI with an unhelpful authorization error.

Provider authentication is provider-specific, commonly sourced from environment variables, workload identity, or a secrets broker. Do not hardcode credentials in provider blocks or variable files. Prefer short-lived dynamic credentials with narrowly scoped permissions. Use terraform providers, schema/docs, provider logs, and API audit logs to isolate failures. Set TF_LOG and TF_LOG_PATH only temporarily and sanitize output before sharing.

Analogy: Credentials are a building badge, not part of the blueprint. The plan may state which door to use, but the badge should be issued to the worker at run time.

A worked configuration

provider "fakecloud" {
  # credentials are discovered from the runtime environment
}

# TF_LOG=DEBUG terraform plan
# unset TF_LOG immediately afterward

CI identity should be attributable to a run, not a shared human. Separate plan permissions from apply permissions where the provider allows it. Provider debug logs and state artifacts belong in the incident's sensitive evidence store, never a public ticket.

Warning: Marking a Terraform variable sensitive redacts normal UI output; it does not prevent a value from entering state, provider requests, debug logs, or a saved plan.

Goal: Reinforce this lesson in the tf-sensitive-outputs Terraform lab. Open /labs/terraform and choose slug tf-sensitive-outputs; the lab runs real Terraform against the offline FakeCloud provider.