Skip to content

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 manager

Supported 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#key
source:
type: git
repo: git@github.com:acme/web.git
auth:
from_vault: secret/acme/web#deploy_key

The 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