Secrets Management in IaC — Stop Hardcoding Credentials in Your Terraform

Infrastructure as code needs secrets. Terraform provisions an RDS instance and needs to set the master password. An ECS task definition needs database connection strings. A Kubernetes deployment needs API keys. The question is where those secrets live and how they flow through your system.

The worst pattern is plaintext secrets in .tfvars files or Terraform variables with default values. These end up in Git history, CI logs, and Terraform state. Even if you delete them later, Git history is forever. The second-worst pattern is generating secrets in Terraform (using random_password) but not storing them in a secrets manager — they exist only in Terraform state, which becomes a high-value target.

The correct pattern: generate secrets outside of Terraform or mark them as sensitive within Terraform, store them in a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager), and reference them in your infrastructure code via data sources. Applications read secrets from the secrets manager at runtime, never from environment variables baked into images or task definitions.

AWS Secrets Manager + Terraform: We provision secrets as Terraform resources with the random_password resource for generation and aws_secretsmanager_secret_version for storage. The Terraform code marks the password as sensitive = true to prevent it from appearing in plan output or logs. Applications retrieve secrets at runtime via the Secrets Manager SDK, and ECS tasks use the native secrets block for seamless injection. Automatic rotation is configured for database credentials using Lambda rotation functions.

HashiCorp Vault: For teams needing dynamic secrets (short-lived credentials generated on demand), centralized secrets management across multiple clouds, or advanced policies like leases and revocation. We deploy Vault (self-hosted or HCP Vault) and configure the Terraform Vault provider to provision secret engines, policies, and authentication methods. Applications use Vault Agent or the Vault SDK for secret retrieval. Vault's database secret engine generates unique, short-lived database credentials per application instance — if one is compromised, it expires automatically.

SOPS (Secrets OPerationS): For teams that want encrypted secrets in Git. SOPS encrypts YAML/JSON files with AWS KMS, GCP KMS, or PGP keys, allowing you to commit encrypted secrets to your repository. The CI/CD pipeline decrypts them at runtime using IAM role credentials. We integrate SOPS with Terraform using the sops provider or as a pre-processing step in the pipeline. This approach is simpler than Vault but lacks dynamic secrets and rotation capabilities.

A secure secrets management implementation integrated with your IaC:

• Secrets manager setup — AWS Secrets Manager, Vault, or SOPS configured and provisioned via Terraform
• Secret generation — passwords, API keys, and certificates generated securely and stored in the manager
• Application integration — runtime secret retrieval configured for your services
• Rotation — automatic credential rotation for databases and service accounts
• State cleanup — existing plaintext secrets removed from Terraform state and Git history
• Access policies — least-privilege access to secrets per service and environment
• Audit logging — all secret access logged for compliance and incident investigation