There have been a lot of container escape exploits
Re:Tailscale Kubernetes Operator
by johnmaguire on Friday September 22, 2023 @02:02PM
(#37615405)
Sure... but it's still not "the same as" running on your host.
That depends on how you're running it. You wouldn't want a compromised image to be the base for your build containers, which get access to your product's source code via volume mount, or to secret keys via environment variables.
Re:Tailscale Kubernetes Operator
by peterbecich on Saturday September 23, 2023 @02:43AM
(#37621110)
I'm a big fan of Nix Flakes but they appear to have the same issue here as "curl | bash".
I mention this because Flakes can do much of what Docker can do, but do not use containers or virtualization.
The official NixPkgs are carefully vetted. Nix Flakes make it more convenient to pull in sources from outside NixPkgs.
As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them. There are more benefits to Nix Flakes than native execution so containerizing them somehow might be an acceptable compromise.
> As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them.
You may be interested in nix snapshotter, which can run nix packages in containerd.
While I understand the argument you're making, the exposure of running "curl | bash" on your local machine is much higher than running arbitrary code inside of a container.
Even if you specify a hash, are you actually checking all of the code and binaries in that image?
What about the image base (e.g. Alpine, Debian) and their packages?