The Vault provider & dynamic secrets

Beyond static encrypted files.

SOPS encrypts static secrets you manage in files — excellent, but the secret still exists indefinitely until you rotate it. HashiCorp Vault takes a different, complementary approach: it is a central secrets service that can issue dynamic secrets — short-lived credentials generated on demand and automatically revoked. Its database secrets engine, for example, creates a unique database user per request with a short TTL, so there is no long-lived password to encrypt, leak, or rotate at all.

# Vault mints a fresh, short-lived DB credential on demand (no static password)
$ vault read database/creds/payments-role
username    v-token-payments-x7k2...
password    A1a-9f2b...           # valid for, say, 1h, then Vault revokes it

The Terraform Vault provider

This is the “Vault provider” angle for IaC: the Terraform Vault provider lets Terraform read secrets from Vault at plan/apply time instead of hard-coding them or storing them in tfvars — the source of truth stays in Vault, and Terraform requests what it needs. Combined with dynamic secrets, Terraform can obtain a short-lived credential for the run rather than a durable one. The trade-off versus SOPS: Vault needs a running, highly-available service and more operational investment, where SOPS is just files and a key.

provider "vault" {}                       # authenticates via token/OIDC/etc.
data "vault_kv_secret_v2" "db" {
  mount = "secret"
  name  = "payments/db"
}
resource "aws_db_instance" "db" {
  password = data.vault_kv_secret_v2.db.data["password"]   # pulled from Vault, not tfvars
}
# note: the value still lands in Terraform STATE — protect/encrypt state accordingly