There are serious attempts at secure container runtimes (see gVisor) and runtimes that run container images in a real VM (see Firecracker).

This meme that containers are inherently insecure just because Docker doesn't attempt to be a security product needs to die. Docker hasn't been the only player in the container runtime space for a long time.

Insecure is a very strong word, world has been running on Docker for sometime and it works fine and is not as insecure has you seem to think.

I agree that Docker actually has a relatively good track record, but it is true that Docker will never be on the same level as a VM hypervisor that was designed from the ground up to be a security barrier.

Thus, when people bring up "Docker is insecure" I try not to get down in the weeds arguing about the specifics, and instead point out alternative projects that are designed with security in mind. I find it's a much stronger counterargument.

The world does not rely on docker for security at all, cloud providers put each tenant of container runtimes behind an additional barrier, like a VM.

Secure runtimes are a superior solution to virtualisation and separate kernels. There are only two secure runtimes in common use - for javascriot and webassembly.

The point about hardware support is very unfair - if you invest the same level of effort and hardware support into webassembly, you can also i prove its performance. Thats like compaining that electric cars suck because there are no chargers - its just infra.

I think that security has always been a goal of FreeBSD jails and I believe they are a bit more hardened than docker

Docker only uses namespaces and cgoups.

Docker does not provide and security or isolation.

To have security and isolation with Docker you must use something external like SELinux or AppArmor.

Hope that helps.

Regards.

Docker also uses seccomp.

> Docker only uses namespaces and cgroups.

How is that not isolation?

The docker daemon has basically root over your system, so any escape can end very badly.

Didn't say secure though, just isolated. Often I'm fine with some subset of isolation.

Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM.

Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies. It's more like Flatpak or AppImage, only more popular and easy.

This packaging also includes a kind of network insulation, exposing only the desired ports, making it easy to have VLANs between containers that do not interfere, etc. This is, again, not a serious security mechanism, but more of a convenience, but a very valuable convenience.

> Oh shucks. Docker's value proposition is emphatically not security.

Congratulations, you have just discovered the additional value that WASM will bring to the Docker approach.

WASM is the "run a proper VM" approach mentioned in the first line.

WASM is great, but it solves a different problem.

> Docker's value proposition is convenient, reproducible, self-contained packaging of software.

Docker doesn't solve any packaging problems, though. It just piggybacks off of other package management solutions and allows ad-hoc, unmanaged modifications to OS images (the convenience) and contains that result for easy distribution.

But nothing in that process ensures reproducibility— the package managers wrapped in Dockerfiles are typically non-deterministic: what any set of commands for them will do depends on the state of the internet at the time they run. Similarly, composing Docker layers is not like composing packages: reuse of packaged objects is minimal rather than maximal, granularity is course, dependency management details may vary from container to container (as they may be based on different Linux distros or language-specific package management ecosystems), and it's very easy to end up with software and configuration installed with which there is no associated package management metadata.

Docker doesn't know anything about packages. Container scanning tools that do things like produce a bill of materials or scan for known vulnerabilities inside Docker containers simply have to guess at what distro is installed inside the container and then reconstruct that information in a distro-specific way to the best of their ability! Docker doesn't solve package management issues so much as punt on them (which is, of course, convenient, because package management is hard).

> [Docker is] more like Flatpak [...] only more popular and easy.

I don't think this is a sound comparison, either. Flatpak is a desktop-oriented containerization solution, for packaging graphical software that will predictably need to interact with the local filesystem, GPU, sound, and other resources. It's also a solution that tackles security updates and deduplication in a serious (and effective) way involving some discipline and enriching shared runtimes with actual metadata rather than just composing filesystem layers together.

It may indeed be easier to crap out something which will be considered a valid Docker image than it is to crap out something which will be considered a valid Flatpak application, but that does not make Docker easier. It's not easier for a desktop user to keep a collection of 50 Docker containers patched for security fixes than it is for a desktop user to keep a collection of Flatpak applications patched for security fixes. It's not easier to take a random Docker container and plug it into your operating system's native file picker or sound system for use with graphical applications than it is to do so with a random Flatpak application. It's not easier to determine what the heck exactly is actually installed in a Docker container than it is to see what is in a Flatpak container. It is not easier to plug a random Docker application into your operating system's default password manager, and so on, and so on.

Writing Flatpak packages requires actually thinking about things that Docker doesn't because Flatpak actually solves package management issues (and other things) that Docker doesn't.

Downvotes without replies is always disappointing.

I would be curious to hear what is wrong in my comment above from anyone who has actually worked on general purpose packaging (e.g., written a package to be included in or overlaid onto a ports tree, maintained RPMs built from RPM spec files, run their own Ubuntu PPA, etc.), implemented tools that scan containers (e.g., SCA scanning or SBOM generation tools), or done reproducibility research.

Would someone with an awareness of full-fledged package management solutions based on or built with containers (e.g., Luet, Distri, Flatpak) really argue that having fine-grained abstractions for reasoning about dependencies or shared runtimes, performing security updates, etc., makes no difference as to what kind of software we're talking about and what problems it solves?

To me it seems obvious that

  - not all software distribution mechanisms are package management solutions
  - Docker cannot see or reckon with individual packages
  - the Docker ecosystem relies on rather than replaces package managers, build systems, etc.

and so on. Are there serious arguments to be had here about those things, or do people just feel like my earlier comment was somehow unkind to Docker?

Docker containers solve the packaging-for-deployment problems that a ton of people used to have. Were they not solving it, they won't be so predominant.

Docker does handle deduplication on a certain level: every layer is only built once, and shared among all images that use it. This can be strategically used to seriously reduce the summary size of your containers.

Desktop users are not the target audience of Docker, except if you consider running a sham prod configuration on your dev machine desktop use. Containers are intended for the server side, and they are fine there.

Not sharing too much, and plainly embracing the existing chaotic practices of software creation and containing them, so that they don't interfere with each other, is the core value proposition of Docker containers. They do not require you to change your existing key practices at a lower level; your Babel / CMake / pyenv / whatnot setup can remain. But it changes the deployment story of it.

> Docker's value proposition is emphatically not security [...] It's the ability to deploy [...] gnarly and imperfect software

This sounds like a recipe for disaster to me and is why I haven't gotten into Docker.

If the software being deployed is too complicated to build and install without Docker, but Docker doesn't provide secure isolation, how can you be sure that this "gnarly and imperfect" mess of a system is secure?

Docker isn’t billed as a security solution but that doesn’t mean that it doesn’t come with some good defaults. You get some namespace/cgroup/seccomp/etc defaults OOTB which is still probably an improvement over what the organization currently has.

It's not about the software being complicated to install without Docker. It's about Docker making the installation process uniform no matter the software.

I think you're missing the GP's point.

What docker provides is a way to shrink-wrap a given build and all of its runtime dependencies.

Despite popular misconception, what docker does not give you is a deterministic way to build that software. A Dockerfile provides the RUN steps necessary to build the software, but dependencies must still be fetched over the network, introducing non-determinism.

You can spend 6 months happily using the latest release of some image, only to find that there's a critical bug or vulnerability that needs addressing ASAP. It kind of sucks for that complacency to turn to terror when you try to patch the software and rebuild, only to find inscrutable errors due to an absolutely bonkers build system.

"ERR: Version A of Foo is incompatible with version B of Bar"

Okay... but what happened here? What versions were we pulling before? Oh, the precise version isn't pinned in the build system, so.. I dunno. Great. It would really help if I knew if it was A that updated breaking B, or the reverse.

Then multiply that by 1000x.

And then add in (for Debian-esque base images) Apt repositories disappearing over time, git feature branches being deleted, tarballs falling off the edge of the internet, etc.

Now, before someone says "well, that's on you if your Dockerfile obscures so much build non-determinism!"

I agree with that statement! But that is a non sequitur with respect to the original premise: the build systems (and the web of dependencies they pull in) in third-party software you don't have ownership of is getting crazier and crazier, and Docker helps perpetuate this state of affairs, and the industry suffers as a whole.

> Despite popular misconception, what docker does not give you is a deterministic way to build that software.

I read an interesting thought: reproducibility is a spectrum. Docker isn't as reproducible as nix, but when used with version control and ci/cd, is damn more reproducible than zips with code and ftping them to servers.

> how can you be sure that this "gnarly and imperfect" mess of a system is secure?

You can't.

But it's not like escaping a container is going to happen because of a simple bug. You need an exploitable vulnerability in the containerized app that creates a path to escaping the container.

But yeah, if you want to isolate an app for security reasons, then you need a VM.

Right, but if Docker allows us to package much more complicated applications (as opposed to being forced to simplify) that gives the bugs more room to hide and increases the risk of unforeseen interactions resulting in security bugs in the application.

So what I'm trying to say is that making complicated applications easier to deploy doesn't seem like a win unless you also mitigate the increased security risk that comes with more complicated applications.

Isn't gVisor a secure docker runtime?

Sure, it doesn't reuse the kernel, but it's not a VM either.

> you have tp put it in a VM , which gives you a performance penalty

This claim is dubious for many configurations of hardware accelerated virtualization. The hardware creates another ring 0 for each guest kernel, and guests run at the same level as the host. It's true that layering things like filesystems and networking incur overhead, but it's just as easy to pass through a physical disk, and bridge virtual TAP interfaces to physical NICs.

Hardware virtualization is very flexible, and there's a configuration out there that will meet the performance requirements of the vast majority of projects.

A native code VM gives really little performance penalty.

Consider VMs like those which run Javascript, or WASM. JIT compilation can get pretty close to C performance, as JVM and LuaJIT show though, given enough RAM at runtime, and money for development.

runq exists, and gvisor can be used as a docker runtime, so yes docker absolutely can.

How many folks out there need to run arbitrary untrusted code on their systems? I think most of the time, the code they run is either their own or from a trusted third party.

And for those use cases, where secure containment of running applications is not a goal at all (beyond maybe taking some basic precautions), I fail to see any value to recompile it to WASM, CLR, JVM, Z80 bytecode or whatever else.

Those who need isolation - yeah, WASM could be a very solid alternative to having a VM. But it's a pretty niche use case.