Securing IaC State: Vault, OpenBao, and KMS

The Flaw in Traditional State Security

In Infrastructure as Code (IaC), the state file (.tfstate) is the key to the treasure room. It stores plain-text passwords, API tokens, and private keys. Historically, safeguarding this file meant delegating security entirely to third-party remote storage backends like AWS S3 or Google Cloud Storage (GCS).

In many deployments, Terraform state is stored in remote object storage backends such as AWS S3 or Google Cloud Storage (GCS), where encryption is typically handled through Server-Side Encryption (SSE). This introduces a major architectural vulnerability: read access to the bucket equals read access to the raw secrets. If an engineer or a compromised CI/CD worker fetches the state object, the storage layer automatically decrypts it, exposing the entire infrastructure state in plain-text JSON.

While client-side encryption—known as Hold Your Own Key exists in the Terraform ecosystem, HashiCorp gates it behind their commercial, paid tier (HCP Terraform Enterprise). To solve this in the open-source ecosystem, deployments utilize OpenTofu paired with a key management root of trust like HashiCorp Vault, OpenBao, or a Cloud KMS.

Managing the Vault/OpenBao Ecosystem with IaC

When integrating an IaC engine with a dedicated secret engine like HashiCorp Vault or its open-source fork, OpenBao, the relationship works in two distinct directions.

1. The Provider Engine (Managing Vault via Code)

Instead of configuring your security tools manually via a CLI or UI, you use IaC to bootstrap, deploy, and maintain the internal structure of Vault/OpenBao itself. This automates:

• Access Control: Creating policies, roles, and enabling authentication methods (e.g., AppRole, AWS IAM binding, Kubernetes service accounts).

• Secret Engines: Enabling and configuring specific secret backends (e.g., Key-Value stores, Transit encryption engines, Database dynamic secret generators).

• Identity Management: Organizing entities and groups directly from configuration files.

2. The Secrets Manager (Securing the IaC Pipeline)

Conversely, Vault/OpenBao can act as the security guard for the deployment pipeline itself. Because IaC engines require high-privilege cloud credentials to provision infrastructure, the secrets manager secures this process by providing:

• Dynamic Credentials: Instead of hardcoding a long-lived AWS Access Key or Azure Service Principal in variables, the runner authenticates to the Vault, which generates a short-lived, temporary cloud credential that automatically expires after the run completes.

• Client-Side State Encryption: Engines like OpenTofu call the Vault/OpenBao Transit Secrets Engine to natively encrypt the .tfstate file locally in memory before it ever gets transmitted to a remote storage bucket.

• Centralized Auditing: Every secret request, credential generation, or state decryption operation triggers an immutable log entry for strict compliance.

Cloud KMS (Key Management Service) as an Alternative Root of Trust

Cloud KMS providers (such as AWS KMS, Google Cloud KMS, or Azure Key Vault) function similar to Vault/OpenBao do when handling client-side state encryption. They serve as the External Key Provider.

When OpenTofu executes a plan or apply, it does not download your master encryption key. Instead, it passes the state data payload to the Cloud KMS API backend via a secure handshake, leverages the cloud provider’s hardware security modules (HSMs) to perform the cryptographic operations, and writes the resulting ciphertext back to disk or remote storage.

Architectural Trade-offs: Vault/OpenBao vs. Cloud KMS