Interesting... yeah if you think of Docker as an easy way to setup environments that's one thing but if you are intending airtight isolation so processes inside Docker can't "escape" most conventional use cases / discourse haven't really focused on that I think
I'd still rather use docker. I don't mind that the daemon runs as root because there are some things that you need root for anyways! Like binding to privileged ports or setting up networks (use `internal: true` and the daemon will automatically set up iptables rules that limit traffic).
I deploy docker compose files with ansible so everything comes with built in security defaults like rootless, dropped caps, no new privileges, etc. I wish more containers supported running read only (its usually pretty easy to add, just overlooked) and distroless (common for go apps, less so otherwise).
There was a pretty good comment on reddit a while back with a list of hardenings for compose files [1]
This whole privileged port thing is an outdated convention from the time when Linux ran on mainframes. Depending on your use case, it can be perfectly fine to lower it. I have set to `net.ipvX.ip_unprivileged_port_start = 80` on my server so that I can run rootless containers without extra privileges and have them bind to ports 80 and up.
The '--userns=auto' argument is a useful isolation method in both rootless and rootful Podman containers. This allows rootful Podman to orchestrate privileged capabilities while running the container processes in an unprivileged namespace.
Personally I still think this is not enough, and we really need full generalized (not AI-only) microvm support built into docker/podman, like yesterday.
Currently it's difficult to even get a hold of a properly configured minimal kernel (or time-consuming to try to build one) and all the right command-line incantations to even start a one-off microvm using say, qemu, with all the proper storage/networking/etc. bits one needs for production environments. Plus you need to keep that kernel updated very regularly.
I know there's projects like smolvm that try to make this simpler, but I've had some major problems with those solutions as well, and I just feel like the big boys need to step up and support this directly by now.
Containers and security are oxymorons. The flood of page cache cves (which can always be escalated/weaponized to an escape) from the other month is making deploying containers to prod untenable.
As for orchestration - a lot of folks think you need a completely new orchestration system for dealing with vms but we just simply re-use the existing infrastructure that already exists - the public clouds. Those companies have tens of thousands of engineers that are much better than the average engineer at this stuff, custom hardware, custom protocols and close to several decades of existing deployment.
I can build and ship a vm from my laptop/ci to prod on AWS/GCP in ~tens of second. Granted I come from the camp that thinks deploying full blown general purpose operating systems to prod is an increasingly incredibly risky practice.
I deploy docker compose files with ansible so everything comes with built in security defaults like rootless, dropped caps, no new privileges, etc. I wish more containers supported running read only (its usually pretty easy to add, just overlooked) and distroless (common for go apps, less so otherwise).
There was a pretty good comment on reddit a while back with a list of hardenings for compose files [1]
1. https://www.reddit.com/r/selfhosted/comments/1pr74r4/comment...
See the discussion here:
https://github.com/podman-container-tools/podman/discussions...
Currently it's difficult to even get a hold of a properly configured minimal kernel (or time-consuming to try to build one) and all the right command-line incantations to even start a one-off microvm using say, qemu, with all the proper storage/networking/etc. bits one needs for production environments. Plus you need to keep that kernel updated very regularly.
I know there's projects like smolvm that try to make this simpler, but I've had some major problems with those solutions as well, and I just feel like the big boys need to step up and support this directly by now.
runsc (gvisor)
Kata Containers
both drop in replacement for runc
there are others too. one based on libkrun I believe.
As for orchestration - a lot of folks think you need a completely new orchestration system for dealing with vms but we just simply re-use the existing infrastructure that already exists - the public clouds. Those companies have tens of thousands of engineers that are much better than the average engineer at this stuff, custom hardware, custom protocols and close to several decades of existing deployment.
I can build and ship a vm from my laptop/ci to prod on AWS/GCP in ~tens of second. Granted I come from the camp that thinks deploying full blown general purpose operating systems to prod is an increasingly incredibly risky practice.