Terraform Security Best Practices

Terraform Security Is Really About Trust Boundaries

Terraform does not deploy risk by itself. It codifies whatever trust model the team gave it.

That means Terraform security is not just about scanning for open security groups. It is about who can change infrastructure, what provider credentials can do, where state lives, and how exceptions become normal over time.

1. Protect State Like a Sensitive Asset

State files frequently contain:

• resource identifiers
• network topology
• sometimes plain or recoverable secrets
• outputs that reveal sensitive endpoints

Production baseline:

• remote backend only
• encryption at rest
• tightly scoped access to state storage
• versioning and locking enabled
• no state files committed to repos or copied into tickets

Example:

An exposed S3 state bucket can reveal enough about the environment to speed up follow-on attacks even before a direct credential leak is found.

2. Use Least-Privilege Credentials for Terraform Runs

The Terraform execution identity should not be a permanent administrator unless you can defend every action it performs.

Prefer:

• separate roles for plan and apply where feasible
• environment-specific roles
• short-lived federated credentials from CI
• explicit deny controls for obviously dangerous changes where the organization supports them

3. Treat Modules and Providers as Supply Chain Inputs

Terraform security is also software supply chain security.

Review:

• provider version pinning
• module source trust
• internal versus public module provenance
• who can publish shared modules

Do not pull a random module into production because the README looked clean.

4. Keep Secrets Out of Variables and Outputs Where Possible

Weak pattern:

• passing long-lived secrets via variables
• echoing them in outputs for convenience
• storing them where every operator with state access can read them later

Better pattern:

• reference a secret manager resource or identity-based access model
• mark sensitive outputs correctly
• avoid turning Terraform into a secret-distribution system

5. Scan Terraform Before Apply

Every infrastructure PR should answer two questions:

1. What changed?
2. Did it introduce dangerous posture drift?

Use tools such as Checkov, tfsec, or Terrascan in CI, but pair them with review discipline.

High-value checks:

• public exposure of storage or databases
• wildcard IAM permissions
• encryption disabled
• logging disabled
• insecure defaults in load balancers or security groups

6. Add Policy as Code for the Rules That Keep Repeating

If the same high-risk review comment appears every month, turn it into a policy.

Good candidates:

• block public data stores
• require encryption on storage
• restrict open management ports
• require tags or ownership metadata on critical resources

This reduces review fatigue and makes exceptions visible.

7. Review Drift and Manual Changes

Terraform security weakens quickly when teams hand-edit cloud resources after deployment.

If drift is normal, your real configuration is no longer the code.

Use plans, Config or posture tooling, and periodic review to catch resources that no longer match the intended design.

Terraform Security Checklist

• remote encrypted backend with locking
• least-privilege execution role
• provider and module versions pinned
• public modules reviewed before adoption
• no secrets casually passed through state and outputs
• CI scanning enabled for Terraform changes
• policy as code for repeated guardrails
• drift monitored and reconciled

Further Reading

• Terraform CLI Security Model
• HashiCorp Terraform Best Practices
• Checkov Documentation
• tfsec Documentation

Related SecureCodeReviews guides:

• IaC Security for Terraform, Docker, and Kubernetes
• AWS Security Misconfigurations and Fixes
• How to Prevent Supply Chain Attacks in CI/CD

Terraform is safest when it is predictable: controlled state, controlled identities, controlled modules, and controlled exceptions.