pothos
commented
1 year ago Thanks for opening the issue! For the systemd-sysext considerations: It depends whether the image is built to work on any Flatcar version (hence static binaries or a custom library path) or if it is requiring a particular Flatcar version and then it could use dynamic linking.
Package name and purpose Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.
Impact of adding this package to the Flatcar OS image Kata Containers is one of the main pieces around achieving multi-tenancy and confidentiality for containers.
The package improves on the following core values:
The package will increase the image size by: [estimated] MBytes. If added to the base image, it'd increase the image size by a lot as it requires shipping:
This would increase the size of the base image by ~200MB, which makes the package really not desired to be in the base image by default.
However, this is a very good candidate to be using systemd-sysext.
How might this package increase the attack surface: The package may increase the surface attack as it's running by default, at least for now, an extra VMM and an extra binary to share the filesystem between the host and the guest.
All of those can be run using SELinux without any issue, which mitigates the extra attack surface
Benefits of adding this package As Kata Containers is running the workload within a lightweight virtual machine, it helps with the multi-tenancy use case for Kubernetes. Apart from this, Kata Containers is the main piece for Confidential Containers, as it does support TDX / SEV / etc, and may be a very good fit for taking advantage of the HW Confidentiality features.
Additional information Adding Kata Containers is not exactly a simple process, as it'll bring several dependencies such as:
Even if using system-sysext, we need to properly understand whether we want to provide "extensions" for the VMMs themselves, and whether we can depend on those, to avoid having issues with the versions clashing.
Moreover, we need to have a reasonable policy on the guest kernel we ship, to avoid getting into a way too large test matrix
There are also other things to consider, as whether we'd be good to go shipping only one of the hypervisors (as an Intel employee, in a biased suggestion, I'd start with Cloud Hypervisor), and if we ended up shipping QEMU whether we should build it statically or not.
Also, we need to ensure the build environment for the non statically linked parts, or even the statically linked go binaries that rely on glibc being dynamically linked, is exactly the same as the base OS, in order to avoid dealing with a binary linked against a too new version of glibc breaking when running on an older one.