Protecting Secrets in Your Configuration

In the previous lecture we looked at where secrets can leak in Terraform: state files, CLI output, logs, and version control. This article shows practical steps you can apply immediately to reduce that risk across three complementary layers:

Sensitive variables — hide values from CLI output and plans (fast, low-effort).
Environment variables — keep secrets out of version control and CI logs.
External secret stores — production-grade secret management and rotation.

These techniques are often combined in real projects to provide layered protection.

A presentation slide titled "Protecting Secrets in Your Configuration" showing three purple panels about Sensitive Variables, Environment Variables, and External Secret Sources. Each panel gives a short recommendation (hide values in outputs/logs; keep secrets out of version control; don't store secrets in Terraform).

Overview: When and why to use each technique

Technique	Primary goal	Typical use case
Sensitive variables	Prevent secrets from appearing in plan/apply/outputs	Developer or CI workflows where values come from inputs
Environment variables	Avoid checking secrets into VCS; inject secrets in CI	Local dev shells, CI secret stores, or automation scripts
External secret stores	Centralized secrets, rotation, auditability	Production workloads requiring rotations and RBAC

1) Sensitive variables

Terraform lets you mark variable and output declarations with sensitive = true. This prevents Terraform from printing the secret in most CLI outputs and replaces the value with a placeholder in plan/apply. Example variable declaration (variables.tf):

variable "db_password" {
  type        = string
  description = "Administrator password for the database"
  sensitive   = true
}

Use the variable in resources as usual:

resource "aws_db_instance" "app_db" {
  identifier = "app-db"
  engine     = "mysql"
  username   = "admin"
  password   = var.db_password
  # ...other args...
}

If you must expose the secret via outputs, mark the output sensitive as well:

output "db_password" {
  value     = var.db_password
  sensitive = true
}

Typical plan/apply will show:

var.db_password = (sensitive value)

Notes and important caveats:

sensitive hides values from CLI output but does not remove them from the Terraform state file. You must secure your state backend (encryption, access controls, remote backends).
Don’t render sensitive values into templates, logs, or monitoring metrics that intentionally print values.
Avoid terraform console or other debugging tools to dump sensitive values in shared environments.

Marking a variable as sensitive hides its value from CLI outputs, but it does not remove the value from the Terraform state. Protect your state backend (enable encryption, restrict access, and use remote backends) to prevent leakage.

2) Environment variables

Passing secrets via environment variables keeps them out of committed files and supports secure injection from CI/CD platforms.

Terraform variables: prefix with TF_VAR_ (for example, TF_VAR_db_password becomes var.db_password).
Provider credentials: use provider-specific environment variables (e.g., AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, GOOGLE_CREDENTIALS).

Example (Bash):

export TF_VAR_db_password="supersecret!"
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."
terraform init
terraform plan
terraform apply

Best practices:

Never commit export statements that contain secrets. Keep local export files (e.g., secrets.env) out of Git by adding them to .gitignore.
Don’t pass secrets on the command line using -var 'password=...' — shell history and process listings can expose them.
In CI, use the platform’s secret management (GitHub Actions secrets, GitLab CI variables, etc.) and avoid printing the values in logs.

3) External secret stores

For production systems, prefer dedicated secret managers that provide audit logs, rotation, and fine-grained access control. Common services:

HashiCorp Vault — dynamic secrets and strong ACLs.
AWS Secrets Manager / AWS SSM Parameter Store.
Azure Key Vault.
Google Secret Manager.

Pattern: fetch the secret at plan/apply time via a data source, decode it, and pass it into resources or pass a provider-side secret reference when supported. AWS Secrets Manager example:

data "aws_secretsmanager_secret_version" "db" {
  secret_id = "my-app/db-credentials"  # name or ARN
}

locals {
  db_credentials = jsondecode(data.aws_secretsmanager_secret_version.db.secret_string)
  db_password    = local.db_credentials["password"]
}

Use local.db_password with resources, and mark any outputs that expose it as sensitive:

output "db_password" {
  value     = local.db_password
  sensitive = true
}

HashiCorp Vault example:

provider "vault" {
  # Vault connection/auth settings go here
}

data "vault_generic_secret" "db" {
  path = "secret/data/my-app/db"   # adjust for your KV engine/version
}

locals {
  db_password = data.vault_generic_secret.db.data["password"]
}

Important considerations:

Terraform fetching a secret at plan/apply time still risks storing that value in state if you put the raw secret into a resource attribute. Prefer provider-side secret references or server-side injection when available.
Limit Terraform’s permissions to the minimal read-only access needed for secrets and favor short-lived credentials.
Secure and audit access to the secret store itself.

Using external secret stores gives you centralized management and auditability. Combine them with Terraform sensitive declarations and a secure remote state backend to minimize secret exposure.

Summary Checklist

Mark secrets as sensitive in variables and outputs to reduce accidental exposure.
Use environment variables (in developer shells or CI secret stores) instead of committing secrets to files.
Use external secret stores (Vault, AWS Secrets Manager, etc.) for production: enable rotation and auditing.
Protect Terraform state: use remote backends, enable encryption at rest, and apply strict IAM policies.
Avoid passing secrets on the CLI or embedding them in logs, templates, or monitoring outputs.

By combining sensitive declarations, environment variable injection, and external secret stores, you can significantly reduce accidental leakage while keeping secrets as first-class runtime inputs.

Links and References

Terraform variables: https://developer.hashicorp.com/terraform/language/values/variables#sensitive-variables
Terraform outputs (sensitive): https://developer.hashicorp.com/terraform/language/values/outputs#sensitive-outputs
Terraform CLI environment variables (TF_VAR_): https://developer.hashicorp.com/terraform/cli/config/environment-variables#tf_var_name
Terraform console: https://developer.hashicorp.com/terraform/cli/commands/console
HashiCorp Vault: https://developer.hashicorp.com/vault
AWS Secrets Manager: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
AWS SSM Parameter Store: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html
Azure Key Vault overview: https://learn.microsoft.com/en-us/azure/key-vault/general/overview
Google Secret Manager: https://cloud.google.com/secret-manager
AWS data source docs for Secrets Manager: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/secretsmanager_secret_version
Vault data source docs: https://registry.terraform.io/providers/hashicorp/vault/latest/docs/data-sources/generic_secret

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

Protecting Secrets in Your Configuration

Overview: When and why to use each technique

1) Sensitive variables

2) Environment variables

3) External secret stores

Summary Checklist

Links and References

Watch Video

​Overview: When and why to use each technique

​1) Sensitive variables

​2) Environment variables

​3) External secret stores

​Summary Checklist

​Links and References

Watch Video

Overview: When and why to use each technique

1) Sensitive variables

2) Environment variables

3) External secret stores

Summary Checklist

Links and References