Hiding Secrets with Sensitive Variables and Outputs

This guide explains how to prevent accidental secret leakage in Terraform plans and logs by using sensitive = true on variables and outputs. It preserves the original examples and diagrams while improving clarity, flow, and searchability for terms like “Terraform sensitive variable”, “redact secrets in terraform plan”, and “protect secrets in terraform state”.

The problem

When you pass secrets (for example, an RDS password) into a resource via a plain string variable, Terraform will render that value in the console output for terraform plan and terraform apply. Those outputs are commonly stored in CI/CD logs, build artifacts, or screenshots — a frequent source of accidental credential exposure. Example (plain, non-sensitive variable and resource):

variable "db_password" {
  description = "Database password"
  type        = string
}

resource "aws_db_instance" "main" {
  identifier     = "mydb"
  engine         = "postgres"
  instance_class = "db.t3.micro"
  username       = "admin"
  password       = var.db_password
}

Example terraform plan output showing the secret in cleartext:

$ terraform plan

Terraform will perform the following actions:

# aws_db_instance.main will be created
+ resource "aws_db_instance" "main" {
    + password = "MyS3cr3tP@ssw0rd!"
    + username = "admin"
    ...
  }

Plan: 1 to add, 0 to change, 0 to destroy.

This sensitive output will be recorded wherever the command runs (local terminal, Jenkins, GitHub Actions, etc.), increasing the risk of accidental leakage.

The solution: mark variables as `sensitive`

Terraform supports a sensitive = true attribute on both variables and outputs. When set, Terraform redacts the value in the CLI output and logs. The provider still receives the actual secret — sensitive only suppresses printing/echoing. Updated variable with the one-line change:

variable "db_password" {
  description = "Database password"
  type        = string
  sensitive   = true
}

resource "aws_db_instance" "main" {
  identifier     = "mydb"
  engine         = "postgres"
  instance_class = "db.t3.micro"
  username       = "admin"
  password       = var.db_password
}

Example terraform plan output after marking the variable as sensitive:

$ terraform plan

Terraform will perform the following actions:

# aws_db_instance.main will be created
+ resource "aws_db_instance" "main" {
    + password = (sensitive value)
    + username = "admin"
    ...
}

Plan: 1 to add, 0 to change, 0 to destroy.

An infographic titled "What Sensitive Variables Protect" showing two side-by-side lists. The left column (green checkmarks) lists protections like hiding values in terraform plan/apply output and preventing values from appearing in logs, while the right column (red Xs) lists limitations like values still being stored in state files, visible if you open state, transmitted to providers, and not actually encrypted.

Marking a value as sensitive redacts it from output and logs, but does not encrypt it in the state file. To protect secrets at rest, use an encrypted backend (for example, Amazon Simple Storage Service (Amazon S3) with server-side encryption and proper access controls) and state locking.

Use sensitive = true as a fast, low-effort layer of defense to stop accidental exposure in CLI output and CI logs. Always combine it with encrypted backends and strict access controls for robust secret protection.

What `sensitive = true` protects — and what it doesn’t

Use this table for a quick decision matrix:

Protects / Behavior	Explanation
Hides values in `terraform plan` and `terraform apply`	Values show as `(sensitive value)` in CLI output and standard logs.
Prevents accidental printing in error messages and logs	Terraform will avoid echoing the value in common outputs and logs.
Works on variables and outputs	Apply `sensitive = true` to either `variable` or `output` blocks.
Still stored in state	The value is saved in the state file unless the backend encrypts it.
Still transmitted to providers	The real value is sent to the provider (e.g., AWS) as part of resource creation.
Not a substitute for encryption	`sensitive` is masking/redaction, not encryption at rest or in transit.

Why you should still use `sensitive`

CLI output and CI logs are common leak vectors (screenshots, archived logs, shared consoles). Redacting values there eliminates many accidental exposures.
sensitive is a very low-friction control that prevents casual leaks during routine work.
For defense in depth, combine sensitive with secure backend configuration (encrypted S3 buckets, proper IAM, state locking) and secret management tooling (e.g., AWS Secrets Manager, HashiCorp Vault).

Sensitive outputs

You can mark outputs as sensitive to prevent values from being printed to the console or logs by default. Sensitive outputs remain accessible programmatically for automation, but they are redacted in human-facing output. Example outputs:

output "database_endpoint" {
  description = "Database connection endpoint"
  value       = aws_db_instance.main.endpoint
}

output "database_password" {
  description = "Database password"
  value       = aws_db_instance.main.password
  sensitive   = true
}

Behavior notes for sensitive outputs:

After terraform apply, non-sensitive outputs (like database_endpoint) are printed to the console.
Sensitive outputs are redacted in human-facing CLI output and logs: they display as (sensitive value).
Sensitive outputs can still be retrieved programmatically (for example, via terraform output -json if tooling has appropriate access) or by reading the state if you have access. sensitive reduces accidental display; it does not prevent retrieval by authorized processes.

Recommendations and best practices

Always mark secrets as sensitive = true for immediate reduction of accidental exposure in CLI output and logs.
Use secure, encrypted backends for state storage (for example, S3 with SSE + KMS and state locking via DynamoDB).
Limit IAM access to the state storage and Terraform execution environments.
Consider integrating a secret manager (AWS Secrets Manager, HashiCorp Vault) and pass secrets via secure providers or data sources rather than embedding them inline.
Rotate credentials regularly and audit who can access state and CI logs.

Quick reference commands and links

Terraform docs: https://www.terraform.io/docs
State backend encryption: use backend "s3" with server-side encryption and kms_key_id (for AWS S3 + KMS).
CI/CD secrets: use your CI provider’s secret storage (GitHub Actions Secrets, GitLab CI/CD variables, Jenkins credentials).

Useful commands:

Purpose	Command / Example
Show outputs (machine-friendly)	`terraform output -json`
Show a single output value (raw)	`terraform output -raw database_password`
Apply a configuration	`terraform apply`
Plan without secrets in logs (if variables are `sensitive`)	`terraform plan` — sensitive values will be redacted

Summary

Use sensitive = true on variables and outputs to redact secrets from Terraform prints and logs.
This masking reduces accidental exposure but does not encrypt secrets in the Terraform state file.
For robust protection, layer controls: mark secrets as sensitive, encrypt and lock the state backend, enforce IAM restrictions, and use secret management tools.

Course Introduction

Preparing Your Environment

Terraform Foundations

The Core Terraform Workflow

Terraform CLI

Terraform File Structure and Organization

Terraform Configuration - Fundamentals

Understading and Managing Terraform State

Marking Code Reusable

Refactoring Terraform State

Terraform Modules

Managing Resource Behavior and Dependencies

Securing Terraform Configurations

Terraform Troubleshooting

HCP Terraform

Hiding Secrets with Sensitive Variables and Outputs

The problem

The solution: mark variables as `sensitive`

What `sensitive = true` protects — and what it doesn’t

Why you should still use `sensitive`

Sensitive outputs

Recommendations and best practices

Quick reference commands and links

Summary

Links and references

Watch Video

​The problem

​The solution: mark variables as sensitive

​What sensitive = true protects — and what it doesn’t

​Why you should still use sensitive

​Sensitive outputs

​Recommendations and best practices

​Quick reference commands and links

​Summary

​Links and references

Watch Video

The problem

The solution: mark variables as `sensitive`

What `sensitive = true` protects — and what it doesn’t

Why you should still use `sensitive`

Sensitive outputs

Recommendations and best practices

Quick reference commands and links

Summary

Links and references