IaC identity is “change authority”
Infrastructure-as-Code systems don’t just read data; they create and mutate critical resources. That makes IaC credentials equivalent to root access in many environments, and they deserve the same rigor as production service identities.
Separate human intent from automation execution
Humans author changes, but automation executes them. Treat “who approved this plan” and “what identity applied it” as distinct signals, then correlate them in audit logs. This helps keep workflows safe without forcing humans to hold permanent admin credentials.
Plan vs apply: different identities, different permissions
A common control is to give the plan phase read-only or limited discovery access, while the apply phase gets narrowly scoped write permissions. This reduces the blast radius of credential misuse during PR checks and untrusted branches.
Backend and state access is part of identity design
IaC tools often rely on a state backend (object storage, DB, Terraform Cloud). State can contain secrets and resource metadata; secure it with strong identity controls, short-lived tokens, and strict access policies.
Dynamic credentials beat static provider keys
Rather than storing cloud access keys in your IaC repo or CI variables, use OIDC or workload identity to obtain temporary credentials at runtime. This not only reduces secret sprawl but improves auditability because each run gets a distinct identity footprint.
Apply guardrails with policy as code
Use policy engines (OPA, Sentinel, cloud-native policy) to constrain what an IaC identity can do, even if the tool tries to do more. Policy should evaluate desired changes (diffs) and environment boundaries (staging vs prod) before allowing applies.
Cross-account and multi-environment complexity
In multi-account setups, the biggest risk is accidental or malicious “wrong environment” changes. Encode environment into identity (role naming, audiences, claims) and require explicit, separate credentials for prod vs non-prod.
CI/CD is the main issuance point
Most IaC execution happens inside pipelines, so pipeline identity practices apply directly here. A strong pattern is “job identity → token exchange → environment-scoped IaC role.” (See CI/CD and Pipeline Identity and Workload OAuth and Token Exchange.)