Non-Negotiable
Never hardcode credentials in Terraform files. Use secret stores and secure pipeline variables. Sensitive input handling is foundational, not optional.
Security, Secrets & Governance
Secure Terraform execution, protect secrets and state, and apply governance so infrastructure automation stays safe in multi-team environments.
🧒 Simple Explanation (ELI5)
Terraform can build powerful things, which means mistakes or weak permissions can also cause powerful damage. Security and governance decide who can run it, what they can change, and how sensitive values stay protected.
🤔 Why Do We Need It?
- Terraform can create, modify, or destroy critical infrastructure.
- State may contain secrets or sensitive metadata.
- Teams need guardrails, not just trust.
🔧 Technical Explanation
Key security domains include least-privilege identities, secure state backends, sensitive variable handling, code review, policy enforcement, and auditability. Governance may involve naming standards, tagging, policy checks, environment approvals, and module standards.
| Control Area | Example Practice |
|---|---|
| Identity | Use service principals or workload identity with limited permissions |
| Secrets | Store in Key Vault or CI secret stores, not in code |
| State | Restrict access and encrypt remote backend storage |
| Governance | Require tags, naming patterns, and pull-request review |
hcl
variable "client_secret" {
type = string
sensitive = true
}🔐
🌍 Real-World Use Case
An enterprise team uses Azure DevOps to run Terraform with an Azure service connection that can access only the target subscription scope. State lives in a dedicated storage account. Pull requests must pass validation and policy checks before any production apply is approved.
🛠️ Hands-on
Security Checklist
- Use separate identities for dev and prod where appropriate.
- Restrict state backend access to Terraform automation and a small break-glass group.
- Apply environment-specific approvals before production apply.
- Scan code for hardcoded secrets and unsafe defaults.
🐛 Debugging Scenario
Problem: A pipeline can plan successfully in dev but fails with authorization errors in prod.
- Compare identity scope and role assignments between environments.
- Check whether the prod subscription or resource group permissions differ.
- Verify secret retrieval permissions for Key Vault or the pipeline secret store.
⚠️
Hidden Risk
A successful Terraform run does not prove your permissions model is good. It may simply mean the automation identity is overprivileged.
📋 Interview Questions
Beginner
Why is Terraform security important?
Because Terraform can make high-impact infrastructure changes and may handle sensitive values or privileged identities.
How should secrets be handled in Terraform workflows?
Keep them out of code, use secure secret stores or pipeline secrets, and mark variables sensitive where appropriate.
Why secure the state backend?
Because state can reveal infrastructure details and sometimes sensitive data, making it a critical asset.
What is least privilege in this context?
Grant only the permissions Terraform needs for the target scope and nothing broader.
Why require pull-request review for Terraform?
Because infrastructure changes deserve peer review, risk assessment, and auditability.
Intermediate
What governance controls are common in Terraform estates?
Tag enforcement, naming standards, module standards, environment approvals, policy checks, and access controls around state and execution.
Why can overprivileged automation be dangerous even if nothing breaks?
Because it increases blast radius, hides poor security design, and allows a compromised pipeline to do far more damage.
How does Key Vault fit into Terraform workflows?
It can store secrets that pipelines or other Azure identities retrieve securely rather than hardcoding them in configuration.
Why separate approval rules for production applies?
Because production infrastructure changes have higher risk and should require stronger control than lower environments.
What is the security downside of local applies with personal credentials?
They reduce auditability and may execute with broader privileges or inconsistent context compared to controlled automation.
Scenario-Based
A repository contains a hardcoded client secret. What do you do first?
Rotate the credential immediately, remove it from code, update the workflow to use a secure secret source, and assess exposure history.
A team says prod and dev use the same Terraform identity for simplicity. What is your view?
That is usually a weak separation model. Environment boundaries should be reflected in identity and approval design wherever practical.
How would you explain Terraform governance to leadership?
It is the set of controls that ensures infrastructure automation is consistent, approved, auditable, and aligned with enterprise security standards.
A pipeline passes but creates resources without required tags. What is missing?
Either the module standards or policy enforcement is insufficient. Governance must be embedded, not assumed.
Why is secret handling still relevant if variables are marked sensitive?
Because sensitivity controls output display, but it does not replace secure storage, least privilege, or backend protection.
🧾 Summary
Terraform security is not only about hiding secrets. It is about controlling execution, reducing blast radius, and governing infrastructure change so automation stays trustworthy as the platform grows.