Lab: Keep Supported Secrets Out of Terraform State

Compare traditional secret arguments with Terraform write-only and ephemeral patterns across AWS and Azure, then scan state for accidental exposure.

Overview

This lab demonstrates where secrets enter Terraform state, which supported resources can use write-only or ephemeral values, and how to scan state safely during migration.

The website intentionally does not mirror this repository. The GitHub repository is the canonical, versioned lab so its Terraform, scanner, workflow, and tests cannot drift into a second downloadable copy here.

Requirements

  • Terraform 1.11+ for write-only managed-resource arguments
  • AWS provider 5.88.0+ for secret_string_wo
  • AzureRM provider 4.25.0+ for value_wo
  • jq, plus authenticated AWS or Azure tooling for the examples you run

Start Here

  1. Read the companion article for the state-security model and supported-resource caveats.
  2. Open the canonical GitHub repository.
  3. Follow the README through isolated setup, state inspection, the write-only comparison, validation, and cleanup.

Use disposable test secrets only. Treat every state file as sensitive even when the exercise is complete.

Use the repository’s scripts/leak-check.sh instead of printing state values to the terminal. It reports only resource and attribute names and always redacts matched values. Exit code 0 means no obvious match, 1 means a potential leak, and 2 means the scan could not make a trustworthy decision because a tool or state was missing, empty, unreadable, or could not be pulled. CI must treat both 1 and 2 as failures, not as a skipped/pass result.