Encrypt an edge site's root disk

Edge sites often run in physically exposed locations: a retail back room, a factory floor, a roadside cabinet. If someone removes a disk, the data on it must be useless to them. This guide explains how to encrypt the root filesystem of a Linux-based site host and how to choose the mechanism that unlocks it at boot.

note

This is about the host's disk, not the Strongbox vault. Strongbox seals its own secrets independently; see Using a TPM or an HSM and Unseal an Isolated Site for vault sealing. The vault's unsealed state lives only in memory and never touches the disk. Disk encryption protects the data that is at rest on the host - for example container images and application data - before the operating system starts.

The building block is LUKS (Linux Unified Key Setup), the standard Linux full-disk encryption format. LUKS holds up to eight independent key slots, so you can combine an automated unlock method with a human recovery passphrase.

Step 1: Choose an unlock method

The hard question is not "how do I encrypt the disk" but "how does the disk unlock at boot without a person standing at every site." Pick the method whose trade-offs match your threat model.

Method	Unlocks automatically when	Resists	Main cost
Passphrase	a person types it at the console	everything, until typed	needs a human at every boot
TPM-sealed	the same machine boots with unchanged firmware/boot chain	disk removed and read elsewhere	a powered, intact machine still unlocks itself; TPM must be present
Network-bound (Tang/Clevis)	the host can reach a trusted key server on the network	disk taken off the trusted network	requires a key server that boots first
Removable USB key	a specific USB key is plugged in	disk taken without the key	the key is a physical object to manage and back up

Most deployments combine one automated method as the primary unlock with a strong passphrase in a separate LUKS slot for disaster recovery.

• TPM-sealed suits a single self-contained host that you trust to boot unattended. The disk is bound to that machine's hardware, so a stolen disk alone will not open. Use systemd-cryptenroll --tpm2-device=auto or the Clevis tpm2 pin.
• Network-bound suits clusters where one machine can act as a key server ("keeper") that the others depend on. The disks unlock only while on the trusted network, and the key never travels the wire. Use Clevis with a Tang server. A separate, more detailed reference build of this pattern is available from Avassa on request.
• Removable USB key suits sites where an operator carries a physical key and "no key, no boot" is the desired property.

Step 2: Encrypt the root filesystem with LUKS

You cannot encrypt a running root filesystem in place safely. Do it one of these ways:

• At install time, if your installer offers LUKS (most Debian, Ubuntu, Fedora, and RHEL installers do). This is the simplest path.
• From a separate system or rescue environment, by backing up the root, reformatting the partition as LUKS, and restoring. This is the path for appliances and single-board hosts whose images do not encrypt by default.

The reformat-and-restore outline, run against an unmounted root partition /dev/sdX2:

# Back up the unencrypted root.
mount /dev/sdX2 /mnt/old
tar -C /mnt/old --one-file-system --xattrs --acls --numeric-owner \
    -cpf /tmp/root.tar .
umount /mnt/old

# Re-create the partition as LUKS. The passphrase here is slot 0, your
# offline recovery key.
cryptsetup luksFormat --type luks2 /dev/sdX2
cryptsetup luksOpen /dev/sdX2 cryptroot
mkfs.ext4 /dev/mapper/cryptroot

# Restore.
mount /dev/mapper/cryptroot /mnt/new
tar -C /mnt/new --xattrs --acls --numeric-owner -xpf /tmp/root.tar

Then point the system at the encrypted device by adding a /etc/crypttab entry and updating /etc/fstab to mount /dev/mapper/cryptroot as root.

Step 3: Enroll the automated unlock method

Always keep the slot-0 passphrase from Step 2 as your recovery key, then add the automated method as a second slot.

TPM-sealed:

systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdX2

Network-bound (Tang/Clevis):

clevis luks bind -d /dev/sdX2 tang \
    '{"url":"https://keeper.example","thp":"<thumbprint>"}'

Pin the Tang server by thumbprint so a rogue server cannot impersonate it.

Removable USB key: add a keyfile that lives on the USB device as a LUKS slot, and reference it from /etc/crypttab so the initramfs reads it at boot.

cryptsetup luksAddKey /dev/sdX2 /path/to/usb/keyfile

Step 4: Rebuild the initramfs and verify

The initramfs must contain the unlock logic and a correct /etc/crypttab. Rebuild it after enrolling:

update-initramfs -u -k all   # Debian/Ubuntu
# dracut -f                  # Fedora/RHEL

Then verify against your threat model before trusting the site:

1. Normal cold boot with the unlock method available: the host boots without a passphrase prompt.
2. Unlock method unavailable (TPM cleared, network down, USB removed): the host falls back to the slot-0 passphrase prompt, or refuses to boot if you removed the fallback.
3. Disk read elsewhere: move the disk to another machine. It must not open without the recovery passphrase.

Operational considerations

• Keep the recovery passphrase safe and separate. It is the only way in if the automated method fails. Store it offline.
• Back up key material. A lost TPM (replaced mainboard), an unreachable Tang server, or a lost USB key all lock you out. Keep backups of Tang keys and USB keyfiles, and record which sites use which method.
• Decide what "key source unavailable" should mean. Falling back to a passphrase prompt keeps a site recoverable but means a person can unlock it at the console. Removing the fallback enforces "no key, no boot" at the cost of recoverability. Choose deliberately per site.
• The initramfs lives on an unencrypted boot partition. Treat anything baked into it (scripts, salts, static keyfiles) as readable by anyone holding the hardware.