Why Ephemeral Resources in Terraform Matter: How MyCoCo Eliminated Secrets from State Files

When organizations manage cloud infrastructure with code, sensitive passwords and access keys often get saved in files where anyone with access can see them—creating major security risks. Terraform v1.10's "ephemeral" features solve this by using secrets temporarily without saving them permanently. Here's how MyCoCo went from failing security audits to achieving SOC 2 compliance by eliminating all exposed passwords from their infrastructure files.

TL;DR

The Problem: Terraform state files store database passwords, API keys, and certificates in plaintext, creating major security and compliance risks.

The Solution: Terraform v1.10's ephemeral resources exist only during execution—never written to state or plan files. They use a unique lifecycle: open → use → close.

The Impact: MyCoCo went from failing security audits due to exposed secrets to achieving SOC 2 compliance by eliminating all sensitive data from state files. Zero secrets in state, improved developer experience, simplified disaster recovery.

Key Implementation: Use ephemeral "aws_secretsmanager_secret_version" to fetch secrets and secret_string_wo (write-only) arguments to store them without state persistence.

Bottom Line: If you're storing secrets in Terraform state files, ephemeral resources aren't optional—they're essential for enterprise security.

The Challenge: MyCoCo's Security Wake-Up Call

MyCoCo started like many tech companies—two DevOps engineers managing infrastructure for a growing startup. As they scaled from 5 to 50 engineers, their Terraform usage expanded rapidly. They were proud of their infrastructure-as-code approach, with everything properly versioned and state files safely stored in an encrypted S3 bucket.

Then came the compliance audit.

"Your Terraform state files contain database passwords in plaintext," the security consultant announced during their SOC 2 preparation. "Anyone with access to your state backend can see every database credential, API token, and private key you manage."

The MyCoCo team was stunned. They'd focused on encrypting state files at rest and restricting S3 bucket access, but they'd never considered what was inside those encrypted files. A quick investigation revealed the scope:

• Database passwords for PostgreSQL and Redis instances
• JWT signing keys for authentication
• SSL certificate private keys
• Third-party API tokens for monitoring services
• SSH keys for bastion host access

Even worse, their disaster recovery procedures included copying state files to a secondary region, and their CI/CD system downloaded state files to runners for each deployment. Every copy contained the same sensitive data.

Their initial attempts to solve this failed. The sensitive argument only hides CLI output—data still goes to state files. External secret management tools proved complex to integrate with existing workflows.

The audit deadline was approaching, and MyCoCo needed a solution that would eliminate secrets from state files without a complete workflow overhaul.

The Solution: MyCoCo's Ephemeral Implementation

Terraform v1.10's ephemeral resources solved MyCoCo's problem. These resources exist only during execution—they're opened when needed, used during operations, then closed. Values never touch state or plan files.

Before: Passwords in State

# OLD APPROACH - Password stored in state
resource "random_password" "db_password" {
  length  = 16
  special = true
}

resource "aws_db_instance" "main" {
  password = random_password.db_password.result  # Goes to state!
}

After: Clean State Files

# NEW APPROACH - No passwords in state
ephemeral "random_password" "db_password" {
  length           = 16
  override_special = "!#$%&*()-_=+[]{}<>:?"
}

resource "aws_secretsmanager_secret_version" "db_password" {
  secret_id        = aws_secretsmanager_secret.db_password.id
  secret_string_wo = ephemeral.random_password.db_password.result
}

The key insight: secret_string_wo is a write-only argument that accepts ephemeral values but doesn't store them in state.

Retrieving Secrets Without Persistence

ephemeral "aws_secretsmanager_secret_version" "app_database" {
  secret_id = aws_secretsmanager_secret_version.db_password.secret_id
}

locals {
  db_credentials = jsondecode(
    ephemeral.aws_secretsmanager_secret_version.app_database.secret_string
  )
}

provider "postgresql" {
  host     = aws_db_instance.main.address
  username = local.db_credentials["username"]
  password = local.db_credentials["password"]
}

This pattern retrieves secrets during Terraform execution without persisting them in the infrastructure-as-code workflow.

Results: MyCoCo's Security Transformation

Complete Secret Elimination: State files went from containing dozens of sensitive values to zero. Security audits could focus on access controls rather than data exposure.

Simplified Compliance: SOC 2 compliance became straightforward when they could demonstrate no secrets persisted in infrastructure artifacts.

Improved Operations: Disaster recovery, state file backups, and vendor sharing became routine operations without security concerns.

Enhanced Developer Experience: Team members could examine state files for debugging without exposing production secrets.

The transition required understanding that ephemeral resources can't be referenced in contexts requiring persistence—but this constraint is the security feature, not a limitation.

Key Takeaways

1. Start with High-Value Secrets: Prioritize database passwords, API keys, and certificates for maximum security impact.

2. Understand Write-Only Arguments: These accept ephemeral values without storing them in state—the key to clean implementation.

3. Plan for Provider Differences: AWS, Azure, and GCP implement ephemeral resources differently based on their native secret management patterns.

4. Validate Implementation: Use terraform show to verify sensitive values no longer appear in state files.

5. Embrace the Constraint: Ephemeral resources can't persist data—this limitation is the security benefit.

Conclusion

For teams still storing secrets in state files, ephemeral resources represent a fundamental shift toward security-by-design in infrastructure-as-code. The investment in learning this approach pays dividends in compliance, security, and operational confidence.

The key is understanding that ephemeral resources solve a fundamental problem: how to use sensitive data in infrastructure code without creating persistent security risks. They're not just a feature—they're a security paradigm that should be standard practice for any organization handling sensitive infrastructure.

Ready to eliminate secrets from your state files? Start by identifying your highest-risk secrets and implementing ephemeral resources with Terraform v1.10.

---

What's your experience with secrets in Terraform state files? Have you implemented ephemeral resources or found other approaches to this security challenge? Share your strategies and lessons learned in the comments below!