In a comment over at !selfhosted@lemmy.world someone wrote:
Containers are not a security barrier. They cannot be, they never will be.
I’m no expert but my mental model of containers was different in that I thought containerized processes live in somehow separate environments, at least filesystem- and network-wise.
I run self-hosted services in containers on my server to isolate them from each other, and now and then binaries I don’t fully trust (things like suspected slop code or not well known python libraries) in containers on my laptop.
Does someone with more technical knowledge about how containers work feel like explaining whether that is a bad idea and if so why? That would be highly appreciated.
Edit: missing words and punctuation.


It’s true that containers were built for reproducibility rather than security, but it’s also true that they can be a helpful tool in securing an environment. Not the ONLY tool, but a helpful one, as they implement kernel namespaces, and, also, tools like podman give you easy access to seccomp-bpf as well. I’ve personally used containers as part of a sandbox for an AI agent, but I integrated quite a lot of security components apart from the container itself, including proper firewall rules on the host level, a landlock ruleset inside the container, a custom seccomp-bpf profile, DNS allowlisting to avoid DNS data exfiltration, and, of course, basic container hardening stuff, like setting the filesystem to read-only, or setting proper uid/gid mapping. There’s a lot you can do with it, but simply containerizing an application won’t secure it by default.
containers were built for a lot more things than reproducibility