Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.
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.
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.
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.
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.
How is that not isolation?
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.
Congratulations, you have just discovered the additional value that WASM will bring to the Docker approach.
WASM is great, but it solves a different problem.
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.
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.
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.
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?
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.
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.
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.
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.
Sure, it doesn't reuse the kernel, but it's not a VM either.
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.
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.
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.
I just wonder how many founders and co-founder fail to understand the crucial value proposition of their business. I suspect one attribute of successful start ups is that over time they come to understand that aspect. And perhaps when we hear of startups "pivoting" that is not the result of a though process but instead a forehead slapping "why didn't I see that?" moment.
If you need to invest significant effort into dumping it, it's almost certainly cheaper to just pay for it. Especially so if the alternative makes any sort of compromise on developer experience.
If it takes two engineers half a year to get a replacement working you're already back in black, and honestly I'm not even sure why (in our specific case) it would take that long when there already are free alternatives.
And this is only the first example I saw. Now we have to root out all apps everywhere across the company that might integrate this tightly with docker.
Then there are performance considerations. Docker Inc apparently did quite a bit to improve performance, especially disk perf. We need to verify all of our existing workflows still work reliably.
None of this is hard, it just takes time and effort.
You had it for free for a long time? Lucky you!
The problem is really more one of "we operated so long without paying and now, blam, everyone pays next year".
It'd be sort of like if github deciding "You know what, everyone now needs to pay $7 a month/user for github". Perfectly within their right, but also a little bit of whiplash for a large number of people.
The next question is if this will last. There's already competitors to docker (rancher/podman/various k8s on my box things).
It seems that their assumptions were correct.
I do agree it is a product that is potentially worth paying for. I do NOT think that the product is worth the amount we were suddenly forced to pay. It felt like extortion.
But that last time was on Intel Macs; maybe the situation is completely different on ARM.
I mostly use the CLI so I have Podman a try and it took less than a single lunch to completely replace Docker for me. Performance is excellent for ARM, and acceptable for the x86 containers I infrequently use.
https://gist.github.com/acdha/9be1c3521af4f18d9f86264a889581...
Do you have links to recent benchmarks? My understanding is that there were investment in bridging the gap recently.
(Comparisons with small input sizes are not informative; look at larger runs.)
As far as I know, wasm won't let me apt-get install a bunch of stuff, set up cron jobs, glue together miscellaneous bash scripts, and magically run it without containers or VMs on any host architecture. That's the use case I'm most familiar with for Docker; wasm as I knew it was just a neat way to run untrusted native code on arbitrary machines with reasonable performance and security.
I think the disconnect is that Docker is also used as essentially a glorified package manager (sort of like Snap), combined with a runtime/interface that makes it convenient for devops purposes. From that perspective, I suppose there's not much difference between running a standalone binary inside its own dedicated Linux environment, and compiling it to wasm to run directly on the host OS, so long as the API remains unchanged.
It's just needlessly confusing to go as far as to call wasm a wholesale replacement for Docker. It's like saying Java is an alternative to Windows.
Well, Docker is not good at this, your Dockerimage can be as non-reproducible as it gets, it just pushes the problem to a different level. Nix and other package managers are the actual solution to this issue.
The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environment, with zero performance penalty.
It's very unlike WASM / WASI approach which requires recompiling stuff, non-runs native code, and completely changes the environment in which the code has to run. It's also like 2x as slow, compared to native code. It has its important upsides, but they are very unlike Docker's, in my eyes.