Secrets, Sensitive Data and Security — Terraform & Infrastructure as Code

Infrastructure as Code introduces a significant security challenge: infrastructure configurations must express sensitive values — database passwords, API keys, TLS certificates, OAuth secrets — but these same configuration files are committed to version control and accessed by CI/CD systems, developers, and potentially shared publicly. The naive approach of hardcoding secrets in Terraform variables or `.tfvars` files creates a severe security risk: a single leaked Git repository exposes all production credentials. Equally problematic, Terraform state files contain sensitive resource attributes (database passwords, generated private keys, IAM access keys) in plaintext JSON — a state file stored insecurely is as dangerous as a credentials file. This lesson covers the full Terraform secrets management stack: marking variables as sensitive, using external secrets managers (HashiCorp Vault, AWS Secrets Manager), securing state storage, and avoiding the most common Terraform security anti-patterns.

Analogy🏏Cricket

🏏 Think of it like cricket: Before standardised cricket rulebooks existed, every ground played by its own local customs — different LBW interpretations, different wide-ball rules, inconsistent DRS protocols. A touring team playing in a new city had to learn an entirely different set of rules. The standardised ICC rulebook is IaC: a version-controlled document that specifies exactly how cricket is played anywhere in the world. When any ground host asks 'how should this match be set up?', they apply the rulebook — not their memory, not local tradition, not a wiki page from 2019. Every ground becomes reproducible because they're all applying the same version-controlled specification. The insight is that codifying rules enables consistency at scale — you can run a thousand simultaneous cricket matches and every one follows the same rules because they all reference the same canonical document.