bottlerocket VS gvisor

There's not one answer to your question, but here's mine: kubelet and AWS SSM (which, to the best of my knowledge will work on non-AWS infra it just needs to be provided creds). Bottlerocket <https://github.com/bottlerocket-os/bottlerocket#setup> comes batteries included with both of those things, and is cheaply provisioned with (ahem) TOML user-data <https://github.com/bottlerocket-os/bottlerocket#description-...>

In that specific case, one can also have "systemd for normal people" via its support for static Pod definitions, so one can run containerized toys on boot even without being a formal member of a kubernetes cluster

Don't overlook Bottlerocket, which despite coming out of AWS is not (AFAIK) AWS-centric: https://github.com/bottlerocket-os/bottlerocket#readme

It's also super handy for writing out static Pod manifests to have replace the brain-damaging Ignition as a less stupid alternative to cloud-init

According to this discussion - starting with Bottlerocket 1.13.0 (Mar 2023) new distributions will default to using Cgroups v2 interface for process organization and enforcing resource limits.

Well, the link I provided references the Bottlerocket docs which explains the control container and the admin container and also how you can configure Bottlerocket via the User Data field when launching it as an AMI. All the information appears to be in the docs

https://github.com/bottlerocket-os/bottlerocket/blob/develop...

On the server-side, there's Bottlerocket OS [1] (Amazon). They use A/B partitions for upgrades, and the idea is that you just run containers for anything non-base. Boot containers are used to do custom configuration at boot, and host-container (or DaemonSet, if you run K8S) is used for long-running services.

[1] https://github.com/bottlerocket-os/bottlerocket

Bottlerocket OS.

To add to the other excellent answers, I would recommend adding Bottlerocket to your reading list: https://github.com/bottlerocket-os/bottlerocket#readme

I'm also aware of (but haven't used) https://github.com/siderolabs/talos#readme

I just realized your question may have implied a desktop os, whereas Bottlerocket, Flatcar, and likely the others in this specific thread are server-side. I don't have much experience with trying to solve that problem on the desktop except for the horror-show that is snap

https://github.com/bottlerocket-os/bottlerocket/issues/2855 soon for bottlerocket, maybe you’ll see Amazon Linux 2023 for eks nodes soon too?

To be pedantic for a moment...

> You can't use Go to write a kernel ...

Not a production kernel, but MIT did use Go to "study the performance trade-offs of using a high-level language with garbage collection to implement a kernel" [1]

There is also gVisor [2] which implements, as best as I can describe, a kernel in user space. It's intent is to intercept syscalls made in containers and to redirect its execution in a sandbox.

> ... program a microcontroller ...

I'm not sure if one would classify this as a microcontroller, but USB Armory did write a, iirc, Go compliant runtime for bare metal ARM and RISC-V [3]

[1] https://github.com/mit-pdos/biscuit

[2] https://gvisor.dev/

[3] https://github.com/usbarmory/tamago

Although the documentation also mentions "youki", that is mentioned as a "drop-in replacement" of the default runtime basically doing the same, so let's stick with runc. The second runtime will be Kata runtime from Kata containers, since it runs small virtual machines which is good for showing how differently it uses the CPU and memory. This also adds a higher level of isolation with some downsides as well. And the third runtime will be runsc from gVisor which is a perfect third runtime to see how we can run containers and still have a little more secure isolation. I will show how we can recognize the differences by running commands from the isolated environments and from the host.

I find the README of the repo much better to quickly understand what this software is and isn't.

https://github.com/google/gvisor

If you think about it virtualization is just a narrowing of the application-kernel interface. In a standard setting the application has a wide kernel interface available to it with dozens (ex. seccomp) to 100's of syscalls. A vulnerablility in any one of which could result in complete system compromise.

With virtualization the attack surface is narrowed to pretty much just the virtualization interface.

The problem with current virtualization (or more specifically, the VMM's) is that it can be cumbersome, for example memory management is a serious annoyance. The kernel is built to hog memory for cache and etc. but you don't want the guest to be doing that - since you want to overcommit memory as guests will rarely use 100% of what is given to them (especially when the guest is just a jailed singular application), workarounds such as free page reporting and drop_caches hacks exist.

I would expect eventually to see high performance custom kernels for a application jails - for example: gVisor[1] acts as a syscall interceptor (and can use KVM too!) and a custom kernel. Or a modified linux kernel with patched pain points for the guest.

[1] <https://gvisor.dev/>

Hillai: Following our research, Alibaba took several steps to address the vulnerabilities we discovered. They limited image pull secret permissions to read-only access, preventing unauthorized uploads. Additionally, they implemented a secure container technology similar to Google's gVisor project. This technology hardens containers and makes them more difficult to escape from, adding another layer of security.

If you want to use netstack without Bazel, just use the go branch:

https://github.com/google/gvisor/tree/go

go get gvisor.dev/gvisor/pkg/tcpip@go

The go branch is auto generated with all of the generated code checked in.

Isn't gVisor kind of this as well?

"gVisor is an application kernel for containers. It limits the host kernel surface accessible to the application while still giving the application access to all the features it expects. Unlike most kernels, gVisor does not assume or require a fixed set of physical resources; instead, it leverages existing host kernel functionality and runs as a normal process. In other words, gVisor implements Linux by way of Linux."

https://github.com/google/gvisor