Provider Identity and Least Privilege

Scenario: Terraform runs with an organization-wide administrator key because it may need to create many kinds of resources.

Split states and workspaces by ownership and permission boundary so each runner needs only relevant capabilities. Prefer workload identity or HCP dynamic credentials that issue short-lived tokens tied to a run. Separate read/plan and apply permissions where practical, restrict destructive actions, and use distinct identities per environment. Provider aliases should not become a shortcut to cross every account boundary from one state.

Analogy: A master key is convenient until it is lost. Separate rooms and time-limited badges constrain both mistakes and attackers.

A worked configuration

# Credentials are injected by the runner; configuration contains no key.
provider "fakecloud" {
  endpoint = var.endpoint
}

Audit provider API calls back to a Terraform run and human approval. Rotate any long-lived credential, alert on out-of-band changes, and ensure a compromised development pipeline cannot assume production roles.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

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