[backlog, low priority] Source encryption key from OpenBao, unsealed/brokered via TPM #20
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
*_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 thanENCRYPTION_KEY/ENCRYPTION_KEY_FILE.crypto.rs's existing resolution order (env → file → data-dir → generate) as another source, rather than replacing what's there.Rough shape (to design later)
Crypto::load_current(before the file/auto-gen fallbacks).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.