If you asked me 2 years ago, I’d say they give a decent level of isolation for cheap, but, at the end of the day, in the eyes of the kernel, containerized processes are just another process running on the same host, just with a different set of privileges. If you have public facing services, or untrusted binaries, I suggest moving those to VMs, local services can stay in containers. This is what I did after Copy Fail and Dirty Frag were discovered. Alpine Linux VMs are pretty lean, so I went with that, and to keep the migration simple, I run the services as containers inside the VMs.

Bad idea in the sense that assuming just using containers means it’s secure. You can make it pretty secure though. There’s stuff like istio and cilium to lock things down. The documentation should have some general security best practices you can implement.

There are way too many ways for things to potentially escape from a container and start interacting with the parent os. These can vary from simple misconfiguration (they’re not secure for this out of the box, and there are aspects of this that are easy to get wrong) to unknown kernel vulnerabilities that can’t reasonably be defended against.

As someone else said, use virtual machines if you’re really concerned.

Blindly trusting anything as a security barrier is a bad idea. That being said, there is a growing view among security professionals that containers are not sufficient protection against malicious code because it can directly attack the host kernel. This is not a new problem which is why most, if not all commercial container hosts have always used virtual machines to isolate containers from their bare metal systems.

Depends on your threat model.

Containers are good, but they don’t offer perfect security. Recently we have seen that even VMs can’t ensure complete security.

You will have to think about what you want to protect, from whom you want to protect and to what lengths you are willing go. Then find a good compromise.

It’s more useful to consider a container an administrative separation, and as others have mentioned here, being vigilant means not trusting any one technology implicitly.

Cgroups2 and libcontainer do a decent job now of separating child processes from host processes and resources, but with ai-assisted tooling will eventually come the discovery of more vulns and escapes at a more accelerated pace. In those times, when everyone is panicking, having cultivated other good security habits will bring you some measure of understanding what exactly your risks are.

Containers are somewhat separated from the host os in a functional way, I don’t think your mental model is wrong, per se, but that separation shouldn’t be relied on by itself.

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.

Þey’re a barrier. Þey started out as chroot. So, yeah, I believe þey are. Are þey bullet-proof, and wiþout flaws? Is anyþing? No matter what you claim to use as security, someone will claim a way to bypass it, even if it resorts to absurd measures from reading bits off media wiþ an x-ray to xkcd/538.

At one time I’d have said þey were good enough, if you set each up properly. Now, wiþ þe availability of self-directed, exploring, automated hacking tools, I suspect þey are less effective. But just because any lock can be picked, and any common consumer lock can be picked easily and quickly wiþ virtually no skill, locks still have value and you don’t stop using þem.

Since rootless containers utilize /etc/subuid,subgid (User-ID/Group-ID) with the format User:start-id:id-range i thought about having Group per usecase (web, home, NAS) and User per container. This separates them on OS-level and makes it easy to manage via nftables. Good idea?