Vault & Secrets
podmaker never stores your secrets in plaintext. It brokers just-in-time leases and resolves references against a secret manager you control.
Two tiers
vault-broker lives in the podmaker network. It authenticates to the meta-cluster vault with AppRole, mints a child token scoped to a single job, wraps it in a cubbyhole, and returns it to the orchestrator. Every issue is audited.
vault-bridge-agent runs inside your network. It long-polls the control plane per workspace, resolves each reference against your own upstream vault, and returns the value — so secrets never traverse or rest in the control-plane database. Bridge tokens are workspace-scoped and cannot cross tenants.
manifest env.from_vault ──▶ orchestrator ──▶ vault-broker (JIT lease) │ ▼ vault-bridge-agent (your network) │ ▼ your secret managerSupported upstreams
The bridge agent proxies to:
- OpenBao
- HashiCorp Vault
- AWS Secrets Manager
- AWS SSM Parameter Store
- GCP Secret Manager
- Azure Key Vault
- Doppler
- Infisical
- 1Password Connect
- Akeyless
- Bitwarden Secrets Manager
- Keeper Secrets Manager
- CyberArk Conjur
- Pulumi ESC
Additional managed engines are registered as canonical engines on the control plane; check your version for the current driver set.
Referencing secrets
In any manifest, use a from_vault ValueRef wherever a value is accepted:
env: DATABASE_URL: from_vault: secret/acme/webdb#url # path#keysource: type: git repo: git@github.com:acme/web.git auth: from_vault: secret/acme/web#deploy_keyThe reference is path#key. At deploy time the orchestrator requests a lease
from the broker, the bridge resolves it, the value is injected, and the lease is
discarded afterward.
Audit
Issue, read and rotation events are written to the control-plane audit log, giving you a compliance trail for every secret access.
→ Marketing overview: Vault & Secrets