Slashdot Mirror
New Hack Shrinks Docker Containers (www.iron.io)
destinyland writes: Promising "uber tiny Docker images for all the things," Iron.io has released a new library of base images for every major language optimized to be as small as possible by using only the required OS libraries and language dependencies. "By streamlining the cruft that is attached to the node images and installing only the essentials, they reduced the image from 644 MB to 29MB,"explains one technology reporter, noting this makes it quicker to download and distribute the image, and also more secure. "Less code/less programs in the container means less attack surface..." writes Travis Reeder, the co-founder of Iron.io, in a post on the company's blog. "Most people who start using Docker will use Docker's official repositories for their language of choice, but unfortunately if you use them, you'll end up with images the size of the Empire State Building..."
Yeah, except that FreeBSD has had 'jails' for over a decade, which are far more secure than anything Docker brings to bear.
The point of Docker is to have a single package ("container") that contains all of its dependencies, running in isolation from any other Docker containers. Since the container is self-contained, it can be run on any Docker host. For example, if you have some wacky old program that only runs on one particular set of library versions, it might be hard for you to get the Docker container just right to make it run; but once you do, that container will Just Work everywhere, and updating packages on the host won't break it.
The point of the news story is that someone did a better job of stripping the container down, removing libraries and such that were not true dependencies (weren't truly needed).
Not only does this make for smaller containers, but it should reduce the attack surface, by removing resources that are available inside the container. For example, if someone finds a security flaw in library libfoo, this would protect against that security flaw by removing libfoo when it is not needed. It's pretty hard for an exploit to call code in a library if the library isn't present. Also, presumably all development tools and even things like command-line shells would be stripped out. Thus a successful attacker might gain control over a docker container instance, but would have no way to escalate privileges any further.
If the stated numbers are correct (a 644 MB container went down to 29 MB) yet the new small package still works, then clearly there is a lot of unnecessary stuff in that standard 644 MB container.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
It's worse, they've combined jails with the equivalent of statically compiled binaries.
Bit of a nightmare when there's a vulnerability on a library used in multiple containers.
Except it isn't. You store your base images in a docker registry, you update that base image, and then you can have your CI environment kick off rebuilds of any dependent images. And as an added bonus you get to test your exact deployable image, including all dependencies, before you actually roll prod. In the past you needed something akin to a Satellite / Spacewalk setup to be able to lock combinations of versions of packages to a point-in-time snapshot. Most people don't seem to do this. They either just auto-update all packages on a regular schedule automatically which would occasionally break things, or they'd let things drift until forced to update by some security vulnerability, which then increases the likelihood of surprises.
Docker is not for everyone, it's certainly overhyped, it's a more complicated stack than more traditional virtualization or bare metal installs, but it doesn't have the specific problem you're imagining it does. In fact, it's a pretty good solution to a lot of the aspects of the problem you bring up.