Fedora image based variants (CoreOS, Atomic Desktops, IoT) are currently built using ostree and rpm-ostree. This enables an hybrid approach where the system is managed like an image but modifications are still possible using RPMs.

But this approach has limits:
- It is difficult for users to customize their operating system and share those customizations.
- The integrity of the boot chain is not guarenteed and it is costly to validate the system content at runtime.

To address those shortcomings, we are introducing the bootable containers (bootc) project. With bootable containers, the content of the operating system, including the kernel and initrd (or a UKI) is shipped in a container image alongside its corresponding base userspace root filesystem. This image can then be modified using container native tools and shared via a container registry.

To chain from platform Secure Boot to a verified root filesystem, the ostree project has integrated support for composefs. It combines multiple Linux kernel features (overlayfs, EROFS and fs-verity) to provide read-only mountable filesystem trees stacking on top of an underlying "lower" Linux filesystem.

We will detail how we are integrating composefs and UKI support in Bootable Containers to enable a trusted and measured boot chain while letting users customize and re-sign their images to fit their needs.

On general purpose image based systems such as Flatcar and Fedora CoreOS, users are encouraged to run all their applications using containers. To make updates safe and predictable, the system is mounted as read only and local modifications are discouraged.

While containers offer a lot of flexibility on Linux, there are still cases where installing binaries or running applications directly on the host operating system is preferred. For example to add kernel modules, use an alternative container runtime version, add more udev rules, etc.

Some of those use cases could be addressed with statically linked binaries, but their management is manual and their usage creates new issues around updates, versionning, memory footprint and not everything can be statically compiled. Alternatively, one can build its own image but at non-negligeable maintenance costs.

Systemd's system extensions (sys-ext) provide a mechanism to extend the content of the host while preserving the safety guarentees around updates. We will demonstrate how Flatcar, Fedora CoreOS and Atomic Desktops are leveraging sysext images to securely extend the OS. With practical examples and usecases (e.g Cluster API) learn how to install Python, Podman, Kubernetes, ZFS, everything at the same time, by composing your very own image with systemd-sysext.