Backing up the age key (#11) changes what happens when the monitoring host's disk dies. It does not change what happens when it walks.
Measured on prometheus (10.0.99.20):
/dev/mapper holds only control and ubuntu--vg-ubuntu--lv — no LUKS anywhere. The root filesystem is plain ext4 on LVM./swap.img, 4 GiB, unencrypted, on that same filesystem.
So ~/.config/sops/age/keys.txt is readable by anything running as robo, and by anyone who takes the disk. Same for the rendered artifacts under stacks/observability/.rendered/ and .env, which by design hold plaintext.
This is very likely an accepted risk for a home lab on recycled hardware rather than something to fix — but SECURITY.md records its other accepted residuals explicitly, and this one is currently unwritten. The ask is one row in that table, not a change to the host.
Relevant because the undo-file leak in #41 was only serious because of this: an undo file at mode 664 on an encrypted disk is a much smaller problem.
Backing up the age key (#11) changes what happens when the monitoring host's disk dies. It does not change what happens when it walks.
Measured on
prometheus(10.0.99.20):/dev/mapperholds onlycontrolandubuntu--vg-ubuntu--lv— no LUKS anywhere. The root filesystem is plain ext4 on LVM./swap.img, 4 GiB, unencrypted, on that same filesystem.So
~/.config/sops/age/keys.txtis readable by anything running asrobo, and by anyone who takes the disk. Same for the rendered artifacts understacks/observability/.rendered/and.env, which by design hold plaintext.This is very likely an accepted risk for a home lab on recycled hardware rather than something to fix — but
SECURITY.mdrecords its other accepted residuals explicitly, and this one is currently unwritten. The ask is one row in that table, not a change to the host.Relevant because the undo-file leak in #41 was only serious because of this: an undo file at mode 664 on an encrypted disk is a much smaller problem.