Learning objectives
By the end of this module, you should be able to:
- Identify Terraform secrets and sensitive artifacts.
- Explain short-lived credential patterns and least privilege.
- Describe team workflow controls such as remote state, policy, approvals and run separation.
Terraform often handles privileged credentials
Provider credentials should be scoped to the minimum required permissions and lifetime. Prefer workload identity or short-lived credentials over long-lived static keys when the platform supports them. Never commit secrets into .tf files or tfvars intended for source control.
Plans and state are sensitive artifacts
Sensitive markings reduce accidental display but plan/state files may still contain secret material. Secure storage, access control, encryption, retention and auditability are operational requirements.
HCP Terraform centralizes collaborative controls
HCP Terraform can provide remote runs, workspaces, variable management, state, policy integration and team access controls. The fundamentals remain the same: configuration is reviewed, plans are evidence, and applies should occur through controlled identity and authorization.
Worked examples
See the idea in practice.
Secret-safe variable declaration
variable "api_token" {
type = string
sensitive = true
}
output "token_present" {
value = length(var.api_token) > 0
sensitive = true
}
- Expressions derived from sensitive values normally inherit sensitivity; a root output derived from a secret must remain sensitive unless you explicitly and safely declassify it.
- Do not output the secret itself merely because an output can be marked sensitive.
- Prefer passing credentials through the provider/runtime mechanism intended for the platform.
Hands-on lab
Lab — Observe sensitive metadata without using a real secret
Goal: Mark a dummy training value sensitive and inspect output metadata safely.
Before you start
- Use only a dummy value; never paste a real token into a lab.
STEP 1Create sensitive training input
mkdir -p ~/gnu-terraform-labs/module11 && cd ~/gnu-terraform-labs/module11
cat > main.tf <<'EOF'
variable "training_secret" {
type = string
sensitive = true
default = "not-a-real-secret"
}
output "training_secret" {
value = var.training_secret
sensitive = true
}
output "secret_configured" {
value = length(var.training_secret) > 0
sensitive = true
}
EOF
STEP 2Initialize and apply
terraform init
terraform apply -auto-approve
STEP 3Inspect normal output
terraform output
STEP 4Inspect output metadata
terraform output -json > outputs.json
grep -q '"sensitive": true' outputs.json
Verify
- Normal output marks both the secret and the derived secret_configured value as sensitive rather than displaying their values in the summary.
- JSON metadata records the outputs as sensitive, demonstrating sensitivity propagation through expressions.
Expected outcome
- You understand that redaction is useful but does not replace secure state and artifact handling.
If it fails
- The lab uses a dummy value because state/JSON inspection can reveal sensitive values to authorized operators.
- A value derived from a sensitive input is also considered sensitive. Use nonsensitive(...) only when explicitly declassifying that derived information is safe and intentional.
- Delete outputs.json after the exercise.
Real-world connectionProduction Terraform should use controlled identities, protected remote state, reviewable plans and separate authorization for privileged applies.
Avoid these traps
Common mistakes
- Committing credentials to terraform.tfvars.
- Assuming sensitive = true encrypts a value everywhere.
- Giving speculative pull-request plans production write credentials.
Knowledge check
Can you explain it without looking back?
Open each answer only after you have tried to answer the question yourself.
1What happens to an expression derived from a sensitive value?
Terraform normally propagates the sensitive marking. A root output using that expression must remain sensitive unless the value is explicitly and safely declassified with nonsensitive(...).
2What credential pattern is preferable when supported?
Short-lived, least-privilege workload identity rather than static long-lived keys.
3Why separate speculative plans from privileged applies?
To limit untrusted or unapproved changes from receiving production mutation privileges.