Reading Secrets from External Sources

Storing secrets directly inside Terraform configuration or variable files increases the risk of accidental exposure. Instead, use a dedicated secrets manager such as AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, or Google Secret Manager. These services are built to securely store and manage secrets, offering features like automatic rotation, access logging, and encryption at rest. Recommended workflow:

Store and rotate secrets in a secrets manager.
Retrieve secrets at runtime (during terraform plan / terraform apply) using provider-specific data sources.
Use the retrieved values when provisioning infrastructure.

This keeps secrets out of .tf and .tfvars files and centralizes management and auditing of sensitive values. Benefits of using an external secrets manager:

Purpose-built secret handling (rotation, audit logging, encryption).
Centralized rotation and access control: rotating a credential in the vault makes the new value available to all consumers.
Reduced secrets in Terraform source files and fewer credentials checked into version control.
A single source of truth for sensitive values across systems.

An infographic slide titled "The Best Practice: Don't Store Secrets in Terraform" showing Terraform retrieving secrets from secret-management tools and then building infrastructure on cloud providers (AWS, Azure, Google Cloud). Below that are four boxes listing benefits like dedicated secrets management, centralized rotation and access control, reduced secrets in Terraform state, and one source of truth.

Terraform, your applications, and other systems can all reference the same secret in the secrets manager. Using a single authoritative secret eliminates ambiguity about which credential is active in production and enables consistent rotation and auditability. Concrete example — AWS Secrets Manager Below is a practical Terraform example that uses the AWS Secrets Manager data source. The data source fetches a secret at plan/apply time and that value is passed to a resource as the database password.

# Read the secret from AWS Secrets Manager
data "aws_secretsmanager_secret_version" "db_pass" {
  secret_id = "production/database/password"
}

# Use it in your resource
resource "aws_db_instance" "main" {
  identifier     = "mydb"
  engine         = "postgres"
  instance_class = "db.t3.micro"
  username       = "admin"
  # Secret is fetched at plan/apply time (at runtime)
  password = data.aws_secretsmanager_secret_version.db_pass.secret_string
}

How this pattern works:

Terraform evaluates data sources during terraform plan and terraform apply, so it queries the secrets manager at runtime and retrieves the secret value.
The secret value never appears in your .tf files or Git—only a reference to the secrets manager path is stored in code.
Note that the secret value can still end up in Terraform state after resource creation. Protect your state by using encrypted remote backends (e.g., S3 with bucket encryption + KMS, Terraform Cloud/Enterprise) and by restricting access.

Ensure the Terraform execution identity has permissions to read secrets from your secrets manager (for AWS, e.g., secretsmanager:GetSecretValue). Configure least-privilege IAM policies for CI runners and developer machines.

Provider-agnostic pattern The AWS example above illustrates the pattern; the same approach applies for other providers and secret stores:

Use the provider integration for the secrets tool (Azure Key Vault, Google Secret Manager, HashiCorp Vault).
Read the secret using a data source or the provider-specific mechanism at plan/apply time.
Inject the returned secret value into the resource configuration.

If you plan to use HashiCorp Vault, consider advanced Vault patterns (dynamic secrets, leasing, and renewal) to further reduce long-lived credentials. Protection quick reference Use the table below as a high-level comparison of common techniques for supplying secrets to Terraform: sensitive variables, environment variables, and external secrets sources.

Approach	Protects logs / console output?	Protects Terraform state?	Protects Git commits?	Best for
Sensitive Terraform variables (`sensitive = true`)	Yes — suppresses output in UI	No — values may still be in state	No — values should not be committed	Hiding sensitive outputs (prevents accidental console leaks)
Environment variables (e.g., `TF_VAR_password`, provider creds)	Yes — not shown in code, but watch CI logs	No — if you then write values into resources, state may contain them	Yes — keeps secrets out of code	CI/local injection of secrets and ephemeral tooling
External secrets manager (data sources)	Yes — values not in code; handle carefully in logs	Partial — state may contain derived secrets; use secure backends	Yes — secret values not stored in Git	Centralized rotation, auditability, production-grade secret management

Recommended defense-in-depth pattern:

Use environment variables to inject secrets during CI/CD or local runs (keeps secrets out of source files).
Store production secrets in an external secrets manager for centralized rotation, audit, and access control.
Mark Terraform variables with sensitive = true to reduce accidental exposure in console output.

In this lesson we covered:

Protecting secrets at the input layer using sensitive variables.
Avoiding secrets in version control by using environment variables for injection.
Integrating Terraform with external secrets managers for secure, production-grade secret handling.

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

Reading Secrets from External Sources

Watch Video