How do you handle sensitive data in Terraform?

Hello @CK_Nitin sir

In Terraform, handling sensitive data like passwords, API keys, or secrets needs extra care. Here are a few ways I usually manage it:

Environment Variables:
I store sensitive values as environment variables and then use var. in my Terraform code. For example, I pass them using TF_VAR_ so they don’t get written into the code.
terraform.tfvars or .tfvars.json:
I sometimes use .tfvars files to keep variable values, but I make sure to never commit these files to Git. I add them to .gitignore.
Marking variables as sensitive:
When defining variables, I set sensitive = true in the variable block. This helps Terraform hide the value during plan and apply. Same for outputs—mark them as sensitive so they don’t get printed in the terminal.
Using Vault:
For more secure setups, I’ve integrated Terraform with HashiCorp Vault to pull secrets at runtime. It keeps everything safe and centralized.
Preventing accidental exposure:
Even with all this, I always double-check the plan output to make sure no sensitive values are getting printed. I also avoid putting secrets directly in the code or state files.

To securely handle sensitive data in Terraform—such as passwords, API keys, or private configuration values—implement structured strategies that manage both how secrets are supplied and how accidental exposure is prevented during the terraform plan and apply phases.

1. Use of Environment Variables

Set sensitive variables as environment variables using the special prefix TF_VAR_. This allows consumption within Terraform without storing secrets in code or on disk. Example:
```
export TF_VAR_db_password="MyS3cretP@ssword"
```
This ensures the value is injected at runtime and not stored in version control or Terraform files.
Environment variables can be easily managed and rotated outside of Terraform, further limiting exposure.

2. Use of terraform.tfvars Files

Store secret values in *.tfvars or *.tfvars.json files. These files can be referenced at plan/apply time:
```
terraform apply -var-file="secret.tfvars"
```
The tfvars files should never be checked into version control. Use .gitignore or equivalent patterns to exclude them (*.tfvars), reducing accidental leaks.
This approach allows teams to separate sensitive data from configuration and clarify which values are secrets.

3. Vault Integration or External Secret Managers

For enhanced security, use HashiCorp Vault, AWS Secrets Manager, or similar secret managers as the authoritative source of sensitive values.
- Terraform can pull secrets directly from Vault using dedicated data sources, such as:
```
data "vault_generic_secret" "db_credentials" {
  path = "secret/database"
}
```
- This keeps secrets out of state and variable files; only pointers or references are kept in Terraform, not the actual secret values.
Secret managers provide auditing, versioning, rotation, and fine-grained access controls, addressing both operational and compliance requirements.

4. Using the sensitive Argument in Variables and Outputs

Mark variables or outputs as sensitive (e.g., sensitive = true):

variable "database_password" {
  type      = string
  sensitive = true
}

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

Terraform hides values flagged as sensitive from CLI output during plan, apply, and destroy operations, reducing the risk of accidental exposure in logs or consoles.
This sensitivity propagates: if a sensitive value is used to derive another value, the derived value is also treated as sensitive.

5. Preventing Accidental Exposure

Marking secrets as sensitive prevents their display in plan/apply output and in most Terraform logs.
For ultimate protection, always review and restrict access to state files, as plaintext secrets can still appear there—even with sensitivity tracking enabled. Use:
- Encrypted remote state backends (e.g., S3 with server-side encryption, protected by KMS keys)
- Fine-grained access control policies for who can read or write state files.
Never output sensitive values unless required, and always use the sensitive = true flag on any outputs that might leak secret information.

6. Additional Best Practices

Do not hard-code secrets anywhere in Terraform configuration, modules, or locals.
Regularly review secrets and rotate them where practical.
Limit the lifetime and scope of any access granted by secrets, enforcing least-privilege principles across Terraform operations and integrations.

Caveats and Limitations

Sensitive values are still stored in the state file, so full protection requires strong backend security (encryption and access control).
Manual diligence is needed to avoid referencing sensitive values in logs or outputs not marked as sensitive.
Vault or similar secret managers add operational complexity but provide higher assurance for secret protection and auditability.

By combining these strategies—environment variables, secure tfvars management, Vault integration, and the sensitive flag—Terraform users can substantially reduce the risk of sensitive data exposure throughout the infrastructure-as-code lifecycle.

2 Replies

Know the answer? Post it — somebody with the same question will find it here.

Sarthak Varshney1y ago
Accepted answer
Hello @CK_Nitin sir

In Terraform, handling sensitive data like passwords, API keys, or secrets needs extra care. Here are a few ways I usually manage it:
1. Environment Variables:
  I store sensitive values as environment variables and then use var. in my Terraform code. For example, I pass them using TF_VAR_ so they don’t get written into the code.
2. terraform.tfvars or .tfvars.json:
  I sometimes use .tfvars files to keep variable values, but I make sure to never commit these files to Git. I add them to .gitignore.
3. Marking variables as sensitive:
  When defining variables, I set sensitive = true in the variable block. This helps Terraform hide the value during plan and apply. Same for outputs—mark them as sensitive so they don’t get printed in the terminal.
4. Using Vault:
  For more secure setups, I’ve integrated Terraform with HashiCorp Vault to pull secrets at runtime. It keeps everything safe and centralized.
5. Preventing accidental exposure:
  Even with all this, I always double-check the plan output to make sure no sensitive values are getting printed. I also avoid putting secrets directly in the code or state files.
Pranshu Singhal1y ago
To securely handle sensitive data in Terraform—such as passwords, API keys, or private configuration values—implement structured strategies that manage both how secrets are supplied and how accidental exposure is prevented during the terraform plan and apply phases.

1. Use of Environment Variables
- Set sensitive variables as environment variables using the special prefix TF_VAR_. This allows consumption within Terraform without storing secrets in code or on disk. Example:
  
  export TF_VAR_db_password="MyS3cretP@ssword"
  
  This ensures the value is injected at runtime and not stored in version control or Terraform files.
- Environment variables can be easily managed and rotated outside of Terraform, further limiting exposure.
2. Use of terraform.tfvars Files
- Store secret values in *.tfvars or *.tfvars.json files. These files can be referenced at plan/apply time:
  
  terraform apply -var-file="secret.tfvars"
- The tfvars files should never be checked into version control. Use .gitignore or equivalent patterns to exclude them (*.tfvars), reducing accidental leaks.
- This approach allows teams to separate sensitive data from configuration and clarify which values are secrets.
3. Vault Integration or External Secret Managers
- For enhanced security, use HashiCorp Vault, AWS Secrets Manager, or similar secret managers as the authoritative source of sensitive values.
  
  Terraform can pull secrets directly from Vault using dedicated data sources, such as:
  
  data "vault_generic_secret" "db_credentials" { path = "secret/database" }
  
  This keeps secrets out of state and variable files; only pointers or references are kept in Terraform, not the actual secret values.
- Secret managers provide auditing, versioning, rotation, and fine-grained access controls, addressing both operational and compliance requirements.
4. Using the sensitive Argument in Variables and Outputs
- Mark variables or outputs as sensitive (e.g., sensitive = true):
  
  variable "database_password" { type = string sensitive = true } output "db_password" { value = var.database_password sensitive = true }
- Terraform hides values flagged as sensitive from CLI output during plan, apply, and destroy operations, reducing the risk of accidental exposure in logs or consoles.
- This sensitivity propagates: if a sensitive value is used to derive another value, the derived value is also treated as sensitive.
5. Preventing Accidental Exposure
- Marking secrets as sensitive prevents their display in plan/apply output and in most Terraform logs.
- For ultimate protection, always review and restrict access to state files, as plaintext secrets can still appear there—even with sensitivity tracking enabled. Use:
  
  Encrypted remote state backends (e.g., S3 with server-side encryption, protected by KMS keys)
  
  Fine-grained access control policies for who can read or write state files.
- Never output sensitive values unless required, and always use the sensitive = true flag on any outputs that might leak secret information.
6. Additional Best Practices
- Do not hard-code secrets anywhere in Terraform configuration, modules, or locals.
- Regularly review secrets and rotate them where practical.
- Limit the lifetime and scope of any access granted by secrets, enforcing least-privilege principles across Terraform operations and integrations.
Caveats and Limitations
- Sensitive values are still stored in the state file, so full protection requires strong backend security (encryption and access control).
- Manual diligence is needed to avoid referencing sensitive values in logs or outputs not marked as sensitive.
- Vault or similar secret managers add operational complexity but provide higher assurance for secret protection and auditability.
By combining these strategies—environment variables, secure tfvars management, Vault integration, and the sensitive flag—Terraform users can substantially reduce the risk of sensitive data exposure throughout the infrastructure-as-code lifecycle.