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. That is the pattern this estate retired. There is no static AWS access key on a workstation for it to hold. There is also no keychain-backed profile in the AWS access path, whether 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 administrator 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 administrator-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 command-line-tool profile (credential_process) resolves each identity on demand. It reads the profile’s OpenBao AppRole, whose secret-zero the run-wrapper supplies from the human-approved bootstrap tier. It then mints a short-lived STS session per call. The run-wrapper delivers the AppRole promptlessly and carries nothing else, and no credential is ever written to the AWS credentials file.

See also