Protecting Secrets in Your Configuration

• Sensitive variables — quick wins that hide values from CLI output and logs.
• Environment variables — keep secrets out of your repository and .tfvars.
• External secret stores — the recommended approach for production.

​

Why this matters

​

Overview: techniques at a glance

​

1) Sensitive variables

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

resource "aws_db_instance" "db" {
  identifier     = "my-db"
  instance_class = "db.t3.micro"
  engine         = "mysql"
  username       = "app_user"

  # Reference the sensitive variable normally
  password = var.db_password

  # ...other settings...
}

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

​

2) Environment variables

• Use the TF_VAR_<name> convention to set input variables from the environment.
• Provider credentials (for example AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, VAULT_TOKEN) are commonly passed via environment variables and are supported by most providers.

export TF_VAR_db_password="s3cr3t!"
terraform plan
terraform apply

• Prefer CI/CD secret stores or OS-level secret managers to inject variables for automated runs.
• Avoid passing secrets via terraform apply -var 'db_password=...' if process-list exposure is a concern.
• Use ephemeral shells and short-lived credentials where possible.
• Remember: if Terraform writes the secret to a resource attribute, the value may still be captured in state.

• Terraform variables — environment variables

​

3) External secret stores (recommended for production)

• Read secret values at apply time and pass them into resources (convenient but may store plaintext in state).
• Configure resources with secret references/IDs (preferred) so Terraform only stores identifiers (ARNs/IDs) instead of plaintext secrets.

• AWS Secrets Manager (reading the secret at apply-time):

data "aws_secretsmanager_secret_version" "db" {
  secret_id = "my-db-password"
}

resource "aws_db_instance" "db" {
  identifier     = "my-db"
  instance_class = "db.t3.micro"
  engine         = "mysql"
  username       = "app_user"

  # Injects plaintext secret read at apply-time
  password = data.aws_secretsmanager_secret_version.db.secret_string
}

• HashiCorp Vault (Vault provider data source):

provider "vault" {
  address = "https://vault.example.com"
  # Authenticate via environment variables like VAULT_TOKEN
}

data "vault_kv_secret_v2" "db" {
  mount = "secret"
  name  = "prod/db"
}

resource "aws_db_instance" "db" {
  identifier     = "my-db"
  instance_class = "db.t3.micro"
  engine         = "mysql"
  username       = "app_user"

  password = data.vault_kv_secret_v2.db.data["password"]
}

• If Terraform reads a secret and writes the plaintext into a resource attribute, the plaintext can end up in state. To avoid this, prefer APIs that accept secret references (for example, pass a Secrets Manager ARN or Key Vault secret reference).
• Design infrastructure to use secret references/IDs where possible so Terraform stores only identifiers.
• Enforce least privilege, short-lived credentials, rotation policies, and audit logging on your secret manager.
• Secure any provider tokens used to read secrets (store them in CI secret stores or encrypted environment variables).

​

Recommended practices (short checklist)

​

Quick reference: do’s and don’ts

• Do: mark inputs/outputs as sensitive to reduce accidental exposure in logs.
• Do: inject secrets via environment variables or CI/CD secret stores rather than committing them.
• Do: use external secret managers in production and prefer passing secret references (ARNs/IDs) to resources.
• Do: secure your Terraform state with a remote backend, encryption, and strict access controls.
• Don’t: hardcode secrets in .tf or .tfvars that are committed to version control.
• Don’t: pass secrets on the terraform command line if process-list leakage is a concern.
• Don’t: assume sensitive prevents secrets from being stored in state—treat state as sensitive.

​

Closing

1. Mark variables and outputs sensitive to reduce accidental exposure.
2. Use environment variables or CI secret injection for development and automated pipelines.
3. Rely on a dedicated secret manager in production—prefer secret references so Terraform does not store plaintext secrets in state.

• Terraform variables
• Terraform state and remote backends