firecracker-containerd

oads running code that I do trust. So far, I feel like I am disagreeing with most of your points. Hazardous? Honestly, laughable. curl'ing a binary and running it has most of the same downsides, but less isolation and it's arguably harder to manage. No matter how you deploy things, no matter how powerful your tools are, you still have to be responsible. Due diligence does sometimes negate the benefit of having a powerful tool, though. Just because the tool lets you ignore some things does not mean that you can actually afford to ignore those things. What's much more hazardous, IMO, is developers running arbitrary code from remote sources locally on dev machines with minimal or no isolation at all. Make one typo to `npx` and you might be screwed. Sure, it's not running as root... but it would be easy enough for it to poison your shell environment and catch you out the next time you try to run sudo, or do any number of other things like steal or use local AWS/Kubernetes/etc. credentials. But I will agree with you on one thing: you should be weary of trusting random Docker images. They're not necessarily secure. You should vet the images you use. Ideally, those images should be as minimal as possible. If at all possible, they should be a single statically-linked binary. If not that, then certainly the absolute bare minimum Alpine userland. ...But, despite that, I think there's so much unneeded fervor over out-of-date Docker images. Part of it is because people want to sell their products, and boy it's so easy to scan a Docker layer and go "See, look! It has this old vulnerability!" Which, sure, I don't disagree that it's bad that ancient bugs are circulating in out-of-date Docker layers, it's a problem that can and should be fixed in most cases. But, honestly, the vast majority of "vulnerability" reports on Docker layers are useless noise. Even this one: XZ Utils backdoor? Docker containers are not virtual machines. I do admit that there are some Docker images that run OpenSSH servers, but it's pretty rare. The gold standard is for a Docker container to map to a single process. You don't really need an OpenSSH server in a Docker container most of the time, unless you're trying to do something specific that needs it (accept Git SSH connections maybe?) And if you're not running OpenSSH in the container, or even sillier, if you don't even have OpenSSH installed, the vulnerability is useless dead code. Anything you could possibly do to the container to exploit this vulnerability wouldn't do any good, because if you have the ability to go and start an OpenSSH server, you don't need the XZ backdoor anymore anyways. This is the reality of most Docker "vulnerabilities". They're not all non-sense, but most of them are just, not real issues that can actually have any impact. Still, I think the way most Docker images are built and distributed could be improved. If we're going to use Dockerfiles, then I think a reproducible system like StageX[1] is much more compelling than starting with `FROM debian:...` in most cases. For many simple cases, like with Go, it's sufficient to just build the binary in one container and then chuck it into a `FROM scratch`. (Side note: recently, I realized that you can entirely avoid copying anything from Alpine these days for Go binaries. You can embed tzdata into Go binaries with an unnamed import to "time/tzdata" now, or by building with -tags timetzdata. Another enterprising person made a similar package for the Mozilla root certificates, and they bothered to make it automatically update, so you can also use that: github.com/breml/rootcerts - and then you don't need to do any funny business, and have a Go binary that "just works" in FROM scratch.) But we don't really need to use Dockerfiles; a lot of tools can build OCI images. I sometimes build OCI containers using Nix. In this case, there's basically no practical disadvantage of using Docker, it's just another way to deploy and schedule some stuff that is constructed with Nix. And if I can just build the software with Nix, I could always just schedule it with Nix, so the obvious question remains; why even bother with Docker? Again, it's because Docker/Podman/Kubernetes offer really useful capabilities. None of the capabilities that any of these tools offer is impossible to get elsewhere, but for example... Having reliable, distributed cronjob scheduling across multiple machines is not typically a trivial endeavor, but it's out-of-the-box on Kubernetes, including scheduling constraints that either control the distribution of load or ensure that workloads run on machines suited to their characteristics and needs, or that they're not scheduled alongside certain other workloads, or what have you. And due to their nature, OCI containers are very flexible. Is Docker's use of Linux namespacing just not enough? No problem: you can get better isolation in multiple different ways. You can use gVisor[2] as a container runtime, giving you a much more proper sandbox, or you can make use of hardware virtualization features using something like firecracker-containerd[3]. Same OCI image, stronger isolation guarantees; and you get multiple choices for what approach to take for that, too. Or you can ignore all this crap, ban Docker and use oldschool VMs, of course, but don't forget to `apt update && apt dist-upgrade` and upgrade to the latest Debian/Ubuntu/whatever on each machine every so often, otherwise you're literally right back at the same problem as with the Docker images... You still have to update the software for it to be updated, after all. (You can do unattended upgrades, too, but nothing stops you from doing the same sort of thing with Docker/Kubernetes, if you like to live dangerously.) Personally though, if I was going to ban anything company-wide, my first choice would be the practice of running dev tools locally with no isolation. You know, there's that Docker tool you can use to do some lightweight local isolation... [1]: https://stagex.tools/ [2]: https://gvisor.dev/ [3]: https://github.com/firecracker-microvm/firecracker-container...

arm64 support!). https://github.com/containers/krunvm https://github.com/slp/krun The orientation as a safe sandbox for AI / MCP tools is a very nicely packaged looking experience, and very well marketred. Congratulations! I'm still not sure why this warrants being it's own project.

include ways to run containers at different levels of isolation (VMs and as micro kernels), so a move to containers can absolutely help security posture, because now you don't have to pull out packer/ansible/etc to build your VM, you can just take the same container you were running and change the runtime. Time to ship/launch improved security features is important, and containers can reduce that burden for teams. Containers are a process isolation and resource control tool -- they can absolutely aid in security posture. Would you say the same about BSD Jails? Just so there's some more value here, here are some projects that are somewhat close to cutting edge (though it's been a while) in this space that I like: - nabla-containers.github.io/ - https://github.com/firecracker-microvm/firecracker-container... - https://github.com/kata-containers/runtime (see https://github.com/kata-containers/documentation/blob/master...) - https://rootlesscontaine.rs/ - https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2... - https://starkandwayne.com/blog/the-capable-kernel-an-introdu... The container ecosystem surfaces a lot of really cool resource limiting and isolation techniques and puts them in very close reach.

ultiple VMM options[2] - linuxkit[3] (let's say you didn't go with kata-containers, this is another container->VM path) - firecracker-containerd[4] (very minimal keep-your-container-but-run-it-as-a-VM) - kubevirt[5] (if you just want to actually run VMs, regardless of how you built them) - Ceph[6] for storage -- make LVM pools and just give them to Ceph, you'll get blocks, distributed filesystems (CephFS), and object gateways (S3/Swift) out of it (in the k8s space Rook manages this) As an aside to all this, there's also LXD, which supports running "system" (user namespace isolated) containers, VMs (somewhat recent[7][8]), live migration via criu[9], management/migration of underlying filesystems, runs on LVM or zfs[10], it's basically all-in-one, but does fall behind in terms of ecosystem since everyone else is aboard the "cloud native"/"works-with-kubernetes" train. I've basically how I plan to run a service like fly.io if I ever did -- so maybe my secret is out, but I sure would like to know just how much of this fly.io got built on (if any of it), and/or what was turned down. [0]: https://news.ycombinator.com/item?id=26745514 [1]: https://github.com/kata-containers/kata-containers [2]: https://github.com/kata-containers/kata-containers/blob/2fc7... [3]: https://github.com/linuxkit/linuxkit [4]: https://github.com/firecracker-microvm/firecracker-container... [5]: https://github.com/kubevirt/kubevirt [6]: https://docs.ceph.com/ [7]: https://discuss.linuxcontainers.org/t/running-virtual-machin... [8]: https://github.com/lxc/lxd/issues/6205 [9]: https://criu.org/Main_Page [10]: https://linuxcontainers.org/lxd/docs/master/storage

own devicemapper snapshotter. From my limited understanding of podman, I believe it's geared more towards security and making containers rootless, which was a pain point in docker initially, since everyone ran containers with root.

out any strong security hardening at all. I think from the similar naming scheme of Firecracker and Bottlerocket you can already see the pieces of the puzzle that are in progress and the future potential though.