zeekayandHanzo Dev f02a592fa4 kms: the store does not open without an at-rest key ...

A missing or malformed KMS_ENCRYPTION_KEY_B64 used to degrade to an
unencrypted ZapDB behind one log line at boot. The deployment it shipped
in ran that way: every credential the fleet syncs sat in cleartext in the
SSTs and the value log, and the S3 replica carried those same cleartext
files off-cluster, so one PVC snapshot or one bucket read was the whole
store. Correct JWT gating in front of a plaintext store does not protect
the bytes.

pkg/atrest is now the one place the key is spelled, validated and used to
open the store, so a server open and a migration open cannot drift into
different databases. An absent key is a refusal to boot, not a warning.
It also names ROOT_ENCRYPTION_KEY in that refusal: that Infisical-era name
is what a Hanzo deployment actually provisions today, and an operator
reading "no key configured" while looking straight at a populated Secret
needs to be told which name counts.

The refusal is only shippable with a way through it. cmd/kms-rekey copies
a store onto a key: the source is opened read-only and never written, the
destination must be empty, and the record count is printed so "it exited
0" is not the only evidence the migration is complete. Rotation of an
already-encrypted store is the same operation with KMS_REKEY_FROM_B64
set — there is no separate rotate path to keep in sync.

It is a separate binary because the server starts serving the moment it
runs: a migration hidden behind an argv word in that binary is one typo
away from starting a second server on the directory it is copying.

Co-authored-by: Hanzo Dev <[email protected]>

2026-08-01 15:32:01 -07:00

..

main.go

kms: the store does not open without an at-rest key

2026-08-01 15:32:01 -07:00