IBM Support

How to Manage Terraform Secrets

Troubleshooting


Problem

 

Introduction:

Terraform relies on sensitive information such as API keys, passwords, tokens, and database connection strings to provision and manage infrastructure resources. Terraform secrets are essential for authenticating services, securing connections, and protecting organizational data. However, storing or handling secrets incorrectly can expose systems to unauthorized access and security breaches. Terraform provides multiple mechanisms for managing secrets securely, including environment variables, secret management tools (such as HashiCorp Vault and AWS Secrets Manager), or encrypted storage solutions.

 

Problem:

Terraform secrets are required across multiple stages of provisioning and operations:

  • Accessing cloud services: AWS, Azure, and GCP credentials are needed to authenticate against APIs.

  • Connecting to databases: Credentials are required to set up and manage sensitive data stores.

  • Configuring networking components: Firewalls, routers, and SSL certificates often require sensitive keys.

  • Automating deployments: Secrets like OAuth tokens or SSH keys allow access to applications and services.

If secrets are exposed or stored in plaintext (directly inside Terraform configuration), it creates serious risks:

  • Unauthorized individuals with access to Git repos, CI/CD logs, or state files can retrieve secrets.

  • It becomes nearly impossible to audit who accessed sensitive values.

  • Infrastructure security is compromised if API keys or access credentials are leaked.

 

Prerequisites:

  • Terraform CLI on your local machine.

  • Access credentials for your target cloud provider (AWS access keys, GCP service account files, etc.).

  • A remote backend (such as S3, GCS, or Azure Storage) for securely storing Terraform state.

 

Solutions:

There are multiple ways to manage Terraform secrets securely. Below are the most common approaches with examples.

 

Example 1:Use Secret Management Tools

Integrate with a centralized secret manager for stronger security:

  • HashiCorp Vault: Dynamic credentials, auto-rotation.

  • AWS Secrets Manager: Store and rotate AWS and database credentials.

  • Azure Key Vault: Manage secrets, certificates, and keys.

  • Google Secret Manager: Secure storage and IAM-based access.

Terraform has providers for each of these services.

 

Example 2: Using Environment Variables

Terraform supports environment variables for securely passing values without hardcoding them into code or state files.

Define variables in variables.tf:

variable "username" {
  type = string
}
variable "password" {
  type = string
}
variable "aws_access_key" {}
variable "aws_secret_key" {}
variable "aws_region" {}

Set environment variables:

export TF_VAR_aws_access_key=<access_key_value>
export TF_VAR_aws_secret_key=<secret_key_value>
export TF_VAR_aws_region=<region>
export TF_VAR_username=<username_value>
export TF_VAR_password=<password_value>

Use variables in Terraform configuration:

provider "aws" {
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
  region     = var.aws_region
}

resource "aws_db_instance" "mydb" {
  allocated_storage    = 10
  db_name              = "mydb"
  engine               = "mysql"
  engine_version       = "5.7"
  instance_class       = "db.t3.micro"
  username             = var.username
  password             = var.password
  skip_final_snapshot  = true
}

This approach avoids hardcoding secrets in code while still allowing Terraform to use them securely.

 

Example 3: Secure Terraform State

  • State files often contain secrets in plain text.

  • Use a remote backend with encryption at rest (e.g., S3 with KMS, Azure Blob with SSE, GCS with CMEK).

  • Restrict access with IAM.

  • Enable state encryption in Terraform Enterprise or Terraform Cloud.

     

Example 4: Securing Terraform with RBAC

Role-Based Access Control restricts system access based on a user’s role within an organization. Instead of giving everyone full access, you grant just enough privileges for their tasks.

TFE has built-in RBAC. Roles can be applied at:

  • Organization level

  • Workspace level

    Common Roles:

  • Owner – Full control over organization/workspaces.

  • Admin – Manage workspaces, teams, and variables.

  • Plan – Can run terraform plan, but not apply.

  • Apply – Can apply infrastructure changes.

  • Read-only – View states and runs, no modifications.

 

Outcome:

By applying these techniques:

  • Secrets are never stored in plaintext in code or state files.

  • Terraform workflows remain secure.

  • Sensitive infrastructure credentials are rotated, encrypted, and centrally managed.

  • Teams can collaborate safely using remote backends and secret management integrations.

 

Key Points:

  • Never hardcode secrets in Terraform code or state files.

  • Use remote backends with encryption and access controls.

  • Leverage environment variables or secret management tools for runtime secret injection.

  • Secure your Terraform application against unauthorized access.

 

Reference:

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSGH5YK","label":"IBM Terraform Self-Managed"},"ARM Category":[{"code":"","label":""}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)"}]

Historical Number

44430695538963

Document Information

Modified date:
16 March 2026

UID

ibm17265573