Skip to main content
Active IaC workspaces do not use aws-vault. Neither does local/manual AWS access anymore.
aws-vault can store long-lived AWS access keys in an operating-system keychain and mint bounded subprocess sessions. It is not part of the dryvist AWS access path, automated or manual. Do not add aws-vault profiles, wrapper commands, or long-lived operator keys to an active IaC repo or a laptop.

​
Terrakube workspaces

Terrakube runs plans and applies; OpenBao mints short-lived STS credentials for each workspace through native dynamic credentials, one scoped broker role per workspace. See Consuming AWS workspace setup.

​
Local and AI-agent access

No static aws-vault base key mints local tf-<project> sessions. OpenBao’s AWS secrets engine brokers this path too, on two layers:
  • A dedicated broker identity whose only IAM permission is sts:AssumeRole into broker-managed roles — it holds no direct resource access itself. Its own base key is seeded into OpenBao once, write-once; rotating it is a deliberate operator action (mint a fresh key on an independent admin path, re-seed), not an automatic process, so no long-lived AWS key sits anywhere routine automation can reach it.
  • Purpose roles behind it — a role per OpenTofu root (for example role/tf-<project>), plus a broader admin-purpose identity for AI and general IaC use. That identity is capped by an AWS permissions boundary that blocks privilege self-escalation, credential/identity persistence (no new IAM users, keys, or login profiles), and audit/org/ billing tampering — it is not AdministratorAccess.
A local AWS CLI profile (credential_process) resolves each identity on demand: it reads the profile’s OpenBao AppRole — whose secret-zero the runtime secret injector supplies from the human-approved Doppler strict tier — and mints a short-lived STS session per call. The injector delivers the AppRole promptlessly, and nothing is ever written to ~/.aws/credentials.

​
See also