Terraform Security Best Practices
Infrastructure as code changed everything about how teams provision cloud resources, faster, repeatable, auditable. It also changed the attack surface. Your Terraform codebase is now a map of your entire cloud environment, and your state file is a live inventory of every resource, credential reference, and configuration detail in it. The hidden tension is that most teams treat Terraform security…
- Terraform state files contain sensitive resource details, encrypted remote backends with access-controlled IAM roles are the floor, not the ceiling
- OIDC federation for CI credentials eliminates long-lived access keys; scope the assumed role to the minimum permissions Terraform actually needs
- Checkov and tfsec at PR time catch misconfigurations before deployment; Conftest with OPA enforces organizational policy that generic scanners can't express
- Secrets don't belong in Terraform variables or state, provision them into Vault or Secrets Manager and let applications pull them directly
- Module pinning and internal registries are your supply chain controls for IaC, a compromised public module is a production infrastructure compromise
Your State File Is A Treasure Map
Terraform state is not just infrastructure metadata. It contains resource IDs, ARNs, IP addresses, and in many cases, depending on your provider and resource types, sensitive values that Terraform needed to manage the resource. RDS master passwords. IAM access key IDs. TLS private keys. The state file for a moderately complex environment is effectively a blueprint for that environment and a partial credential store. The baseline requirement is remote state with encryption at rest and access con
Least Privilege In Terraform CI Is Non-Negotiable
The credentials your Terraform pipeline uses to talk to cloud APIs are the most sensitive secrets in your IaC workflow. They're doing the actual resource provisioning, which means they have write access to your production environment. How you issue, scope, and rotate those credentials determines your blast radius if your pipeline is compromised. OIDC federation is the right pattern for GitHub Actions, GitLab CI, and most modern CI platforms. Instead of storing long-lived access keys as secrets,
Scanning With Checkov and tfsec Must Happen Before Plan
Static analysis tools like Checkov and tfsec scan your Terraform code for known misconfigurations before anything is deployed. Open security groups, S3 buckets without public access blocks, unencrypted EBS volumes, IAM policies with wildcard actions, these are the patterns they catch well. The key word is 'before.' Scanning after deployment means you've already provisioned the misconfigured resource and now you need a fix PR plus a re-apply cycle. Integrate Checkov and tfsec in your CI pipeline
Frequently asked questions
- How do you handle Terraform modules from the public registry securely?
- Pin every module to a specific version tag, not a version range or 'latest.' Read the module source before using it, the Terraform registry shows the source repo, and the actual implementation matters. Run Checkov and tfsec against the module outputs in your plan, not just your root module. For sensitive infrastructure, consider vendoring approved…
- What's the right way to structure Terraform workspaces for multiple environments?
- Separate state files per environment, separate CI roles per environment, and a deployment process that requires plan review before production applies. I prefer directory-based separation (environments/dev, environments/staging, environments/prod) over Terraform workspace commands, the workspace approach shares a single set of code with variable ov…
- How do you deal with Terraform drift, resources modified outside of Terraform?
- Drift is a governance problem as much as a technical one. The technical side: run 'terraform plan' on a schedule in CI (without applying) and alert on drift. Tools like Atlantis, Spacelift, and Terraform Cloud have built-in drift detection. The governance side: if engineers can modify production infrastructure through the console or CLI, they will…
- Is Checkov enough, or do I need both Checkov and tfsec?
- They overlap significantly but have different rule sets and sometimes catch different things. In a CI pipeline where scan time matters, pick one and configure it well, Checkov has broader coverage and is actively maintained with a large rule library. Add Conftest for custom organizational policies. If you're in a highly regulated environment or ha…