[backlog, low priority] Source encryption key from OpenBao, unsealed/brokered via TPM #20

Open
opened 2026-08-07 11:37:10 +00:00 by james.oates · 0 comments
Owner

Priority: low / backlog — hardening, not needed for current deployment.

Idea

Add OpenBao (the Vault fork) as a source for the encryption key — and optionally the master API key — instead of only env var / file / auto-generated file. At startup ER would fetch the key from an OpenBao instance whose unseal (or ER's auth to it) is brokered by a TPM, so the key material is protected by a hardware root of trust and only released to an attested host.

Why

  • Env/file secrets still sit in plaintext on the host (tmpfs for *_FILE, but host-accessible). A TPM-backed OpenBao broker means the encryption key never lives on disk unsealed and is only released to a host that can attest via its TPM — a stronger posture than ENCRYPTION_KEY / ENCRYPTION_KEY_FILE.
  • Additive: slots into crypto.rs's existing resolution order (env → file → data-dir → generate) as another source, rather than replacing what's there.
  • Same OpenBao instance as #11 (routing OpenBao host access through ER) — different integration, worth designing alongside it.

Rough shape (to design later)

  • Config/env pointing ER at OpenBao: address, auth method, and the secret path holding the encryption key.
  • ER fetches the key at startup and feeds it into Crypto::load_current (before the file/auto-gen fallbacks).
  • The TPM broker itself — how OpenBao is unsealed (TPM-sealed unseal keys) and/or how ER authenticates to it (TPM-attested identity) — is mostly infra/homelab-side and needs its own design.
  • Consider covering the master API key (#19) via the same mechanism.

Notes

Depends on an OpenBao instance being available (see #11). Filed from a conversation where it was written "OpenBoa" — read as OpenBao; correct if that's wrong. Surfaced 2026-08-07.

**Priority: low / backlog** — hardening, not needed for current deployment. ## Idea Add OpenBao (the Vault fork) as a source for the encryption key — and optionally the master API key — instead of only env var / file / auto-generated file. At startup ER would fetch the key from an OpenBao instance whose unseal (or ER's auth to it) is **brokered by a TPM**, so the key material is protected by a hardware root of trust and only released to an attested host. ## Why - Env/file secrets still sit in plaintext on the host (tmpfs for `*_FILE`, but host-accessible). A TPM-backed OpenBao broker means the encryption key never lives on disk unsealed and is only released to a host that can attest via its TPM — a stronger posture than `ENCRYPTION_KEY` / `ENCRYPTION_KEY_FILE`. - Additive: slots into `crypto.rs`'s existing resolution order (env → file → data-dir → generate) as another source, rather than replacing what's there. - Same OpenBao instance as #11 (routing OpenBao host access through ER) — different integration, worth designing alongside it. ## Rough shape (to design later) - Config/env pointing ER at OpenBao: address, auth method, and the secret path holding the encryption key. - ER fetches the key at startup and feeds it into `Crypto::load_current` (before the file/auto-gen fallbacks). - The TPM broker itself — how OpenBao is unsealed (TPM-sealed unseal keys) and/or how ER authenticates to it (TPM-attested identity) — is mostly infra/homelab-side and needs its own design. - Consider covering the master API key (#19) via the same mechanism. ## Notes Depends on an OpenBao instance being available (see #11). Filed from a conversation where it was written "OpenBoa" — read as **OpenBao**; correct if that's wrong. Surfaced 2026-08-07.
Sign in to join this conversation.
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
IsoHex/edge-router#20
No description provided.