kuasar VS containerd

Right now most early examples alas boot a container with a wasm runtime for each wasm instance, which is a sad waste. The whole advantage of wasm should be very lightweight low overhead wasm runtime instances atop a common wasm process. Having a process or container for each instance loses a ton of the benefit, makes it not much better than a regular container.

Thankfully there is work like the Containerd Sandbox API which enables new architectures like this. https://github.com/containerd/containerd/issues/4131

It's still being used to spawn a wasm processes per instance for now, but container runtime project Kuasar is already using the Sandbox API to save significant resources, and has already chimed in in comments on HN to express a desire to have shared-process/multi-wasm-instamxe runtimes, which could indeed allow sub ms spawning that could enable instance per request architectures. https://github.com/kuasar-io/kuasar

curl -LO https://github.com/containerd/containerd/releases/download/v2.0.0/containerd-2.0.0-linux-amd64.tar.gz sudo tar Cxzvf /usr/local containerd-2.0.0-linux-amd64.tar.gz

Notably, io_uring syscall has been a significant source of vulnerabilities. Last year, Google security team decided to disable it in their products (ChromeOS, Android, GKE) and production servers [1].

Containerd maintainers soon followed Google recommendations and updated seccomp profile to disallow io_uring calls [2].

io_uring was called out specifically for exposing increased attack surface by kernel security team as well long before G report was released [3].

Seems like less of a rust issue and more of a bug(s) in io_uring? I suppose user space apps can provide bandaid fix but ultimately needs to be handled at kernel.

[1] https://security.googleblog.com/2023/06/learnings-from-kctf-...

[2] https://github.com/containerd/containerd/pull/9320

[3] https://lwn.net/Articles/902466/

So once we had a single binary, then "Docker, Inc" started separating the functionalities into multiple binaries on Linux. That was the beginning the of dependencies and components we have today, except that these dependencies are now not limited to Docker. containerd can also be the container runtime of Kubernetes.

OCI Runtimes: Containerd Overview

Containerd

Containers are everywhere, and containerd is one of the standards for container runtimes. It is a container runtime that is designed to be simple, secure, and efficient. It is used to run containers in a containerized environment, and it is the runtime for Docker!

Container engine security focuses on the underlying runtime system that manages and executes containers, such as Docker, containerd, or CRI-O. These container engines are responsible for interfacing with the operating system kernel to provide the isolated environments that containers run within.

Container Runtime: The engine that actually runs the container (e.g., Docker or containerd).

Containerd is an open-source project originally created by Docker Inc. and is now a graduated project of the Cloud Native Computing Foundation (CNCF). It is a container runtime that's part of the Docker ecosystem, but it can also be used as a stand-alone. It's designed to handle the execution and lifecycle management of containers and provides a robust and reliable runtime that can be embedded into higher-level systems such as Docker, Kubernetes, and other container orchestration platforms.

Note: For production environments, ensure TLS certificates are correctly configured. Refer to containerd documentation for additional configuration details. Once configured, k0s will utilize these settings to pull private images from your registry as needed.