Why Secrets in Terraform Are Risky

• Terraform state contains the complete representation of resources it manages, including attributes marked sensitive by providers or supplied by you.
• That state is serialized to JSON (local terraform.tfstate or a remote backend). If not protected, anyone with read access can view secrets.
• Other parts of a typical workflow — CLI output, CI logs, *.tfvars files, and plan artifacts — are additional exposure points.

​

1) State files

• What: The terraform.tfstate file (local) or the JSON stored in your remote backend contains resource attributes and outputs — including passwords and API keys.
• Risk: Anyone with read access to the backend or the local file can extract secrets. Depending on backend configuration, state may be stored unencrypted.
• Mitigations:
  • Use remote backends that support encryption at rest (for example S3 with KMS, or a managed backend such as Terraform Cloud).
  • Enforce least-privilege access and audit who can read state.
  • Enable state locking to avoid concurrent write issues (integrity), though locking does not hide secrets.
  • Where possible, avoid storing raw credentials in resources; keep only resource IDs in state and reference secrets from a secrets manager at runtime.

{
  "version": 4,
  "terraform_version": "1.5.0",
  "serial": 1,
  "lineage": "00000000-0000-0000-0000-000000000000",
  "outputs": {
    "database_password_output": {
      "value": "MySuperSecretPassword123!",
      "type": "string",
      "sensitive": true
    }
  },
  "resources": [
    {
      "mode": "managed",
      "type": "aws_db_instance",
      "name": "main",
      "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "password": "MySuperSecretPassword123!"
          }
        }
      ]
    }
  ]
}

​

2) Logs and console output

• What: terraform plan, terraform apply, provider error messages, and CI logs can include values or errors that reveal secrets.
• Risk: CLI and CI logs are often retained and readable by many people or systems; leaking a secret into those logs can make rotation necessary.
• Mitigations:
  • Mark outputs and variables as sensitive to hide them from plan/apply output and many UI views (note: this does not remove them from state).
  • Avoid echoing sensitive values in shell scripts or debug output.
  • Use CI/CD platform secret masking and do not write secrets to build logs.

​

3) Version control (Git, etc.)

• What: Files such as terraform.tfvars, hard-coded values in .tf files, or accidentally committed plan files can include secrets.
• Risk: Git history preserves secrets even after removal; public repositories or compromised accounts can leak credentials broadly.
• Mitigations:
  • Never commit *.tfvars files that contain secrets; add them to .gitignore.
  • Use environment variables or your CI/CD provider’s secret store instead of hard-coding values.
  • If a secret is committed, rotate the secret immediately and purge it from history with git filter-repo or BFG Repo-Cleaner.
  • When you must keep configuration with code, encrypt secrets (e.g., Mozilla SOPS) rather than storing plaintext.

​

4) Plan files and CI artifacts

• What: terraform plan -out=plan.tfplan produces a plan that may include values. CI artifacts (build outputs, archived plans) can retain these artifacts.
• Risk: Storing plan artifacts or serialized outputs in artifact storage can leak secrets to anyone who can access those artifacts.
• Mitigations:
  • Avoid persisting plan files if they contain sensitive values; prefer ephemeral pipelines that run plan and apply together in a controlled environment.
  • If you must store artifacts, secure the storage and limit access, apply strict retention, and consider encryption.
  • Configure CI to avoid exporting or logging resource attribute values unnecessarily.

• The sensitive meta-argument reduces surface area by hiding values from CLI and some UI output, but it does not stop Terraform from writing those values into state. Provider schemas can mark attributes sensitive so Terraform hides them in displays, but state remains authoritative.

• How sensitive affects display behavior for variables and outputs.
• How to secure state backends (S3 + KMS, Terraform Cloud, etc.) and apply access controls and locking.
• Provider-specific techniques to avoid leaking secrets in attributes and logs.
• How to integrate external secrets managers (for example, HashiCorp Vault) so credentials are provisioned or referenced securely rather than hard-coded.
• CI/CD best practices: mask secrets, avoid storing plan artifacts, and rotate secrets quickly if exposed.

• Terraform Cloud
• HashiCorp Vault
• Mozilla SOPS
• Kubernetes Basics (for related secrets management patterns)
• Terraform Associate Certification: HashiCorp Certified (https://learn.kodekloud.com/user/courses/terraform-associate-certification-hashicorp-certified)