Sealed Images

While RHEL10 supports sealed images as a Technical Preview and the upcoming Fedora 45 adds --composefs and --bootloader flags to kickstart's bootc command, Kheeper already supports booting images sealed with your own keys. This feature can be used today with bare metal hosting providers that provide access to the Secure Boot configuration in the UEFI setup menu. We recommend latitude.sh for trying out this feature on dedicated servers for as little as $0.81/hour.

The Unsealed Way

The official fedora-bootc images include bootupd, which installs GRUB and a shim that can verify kernels signed by Fedora. The shim is in turn signed by Microsoft and can be verified by enabling Secure Boot and ensuring Microsoft's UEFI CA is trusted. That means the chain of trust relies on a third-party and ends at the kernel.

The Sealed Way

With sealed images, organizations can sign every file in their image with their own keys. The kheeper secureboot init command generates private keys for signing on your workstation and uploads the certificates to Kheeper. Kheeper will automatically install the certificates on hosts created with the --composefs flag.

When you create a sealed release for a composefs host, the kheeper CLI will automate the steps of building your rootfs, signing the systemd bootloader with your key, and generating and signing a UKI. The registry will reject attempts to create an unsealed release image for an enforcing host.

Tradeoffs

• Soft reboots are not possible. Every release triggers a full reboot.
• Creating a sealed release requires downloading the full base image and uploading an additional layer with EFI executables in addition to the configuration layer.
• One time setup in the UEFI firmware setup utility is required to flip on Secure Boot.
• Filesystem is ext4 because fs-verity is not compatible with xfs.

Check out our full sealed images guide for a tutorial and tips.