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..."
and sure enough, it did!
What are they talking about, and why do I care about the size of the container Levi's ships my Docker khakis in?
"National Security is the chief cause of national insecurity." - Celine's First Law
Isn't the attack surface governed by the ports you open up on the Docker containers?
Wasn't a common library the entire point of Docker? Packaging the libs with the app, etc, to reduce dependence on the host OS?
Will it make using Docker any easier on OSX? Why o why does it need to install an Ubuntu VM guest and run Docker inside that??
iocage create -c
Congratulations, you've just (almost) caught up to decade old technology.
http://phk.freebsd.dk/pubs/san...
If these are so much better, why aren't they just the official repos?
-SaNo
Their github lists Perl but not C++?????
Unless things have changed, Docker makes use of a feature of the Linux that allows creating processes that are in their own namespace. This feature requires the Linux kernel something that Mac OS X with its BSD kernel does not possess. It might be possible to do something analogous in a BSD kernel, but I don't know about it. Maybe someone else could comment on it?
FreeBSD got jails some years ago for the same purpose, and IIRC that was one of the inspirations for the linux version. (Both inspired by containers in Solaris, and earlier iterations of the idea in other OSes).
Not that that matters on the MacOS side; the OS X kernel is a weird hybrid thing with a BSD kernel hanging off a Mach microkernel. The BSD parts aren't exactly a full and current FreeBSD, either; IIRC they grabbed a subset they found useful a bunch of years ago. At a guess the jail support didn't make it.
> "Less code/less programs in the container means less attack surface..."
*fewer
Alpine is a horrible choice for a base image because their distribution uses musl libc instead of glibc, which causes horrible problems for things like JVM processes. You can also do fun things like track down segfaults from python processes because of subtle differences in the way unicode characters are rendered to screen.
I was using Alpine as my base image for several months and just recently switched to Amazon Linux to match my container and host OS.
Disk space is incredibly cheap compared to the standard size of a docker image and your "attack surface" is going to be limited in a docker image anyway. Sure, your application loaded in your docker image might add to that surface, but that's going to happen if you use the big image or the small one. The only real reason to do this is so you can run docker images on smaller embedded devices where resources are limited (Not that I see much of that yet).
IMHO, this development is meaningless to me. Thanks for the disk space back, but I didn't really need it...
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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...
What's that in Libraries of Congress?
Yeah, except that FreeBSD has had 'jails' for over a decade, which are far more secure than anything Docker brings to bear.
"FreeBSD got jails some years ago for the same purpose, and IIRC that was one of the inspirations for the linux version. (Both inspired by containers in Solaris, and earlier iterations of the idea in other OSes)."
Actually, I believe Jails were first. In order:
1- UNIX chroot
2- FreeBSD jails
3- Solaris Zones
4- Linux Containers
Although you describe a common case, it's not the general one. In principle the size of a software attack surface is given by the amount of code which is reachable through an attack conduit like a network, not by the "width" of the conduit.
For example, a given network service could be bound to just one IP address or to two, but its attack surface would remain the same despite double the size of the attack conduit. Likewise, a given service could be available on only one port or on N ports, yet its attack surface would not change despite any increases in the size of the conduit through which it can be reached.
(The attack surface is primarily a function of the amount of externally reachable code because the number of exploitable weaknesses is relatively constant per unit of code. Making the same code reachable through a wider conduit does not generally change its set of exploitable weaknesses.)
This assumes that the same code is being exposed regardless of the number of different IP address or port bindings of course. If this is not true because different functionality is offered on different ports then of course the size of the attack surface is no longer invariant.
Your observation is accurate in practice because the special case of "one port per service" is a very common one. It's worth recognizing that the general case is different though.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
So at this rate, Hurd which is also "hanging off a Mach microkernel" is more likely to have native Docker supporter before OS X. :)
Rump kernels enable you to build the software stack you need without forcing you to reinvent the wheels. ... As a production-ready example, we offer the Rumprun unikernel, which clocks in at a few thousand lines of code plus rump kernel components, and supports POSIX'y software directly on both raw hardware and cloud hypervisors such as KVM and Xen.
http://rumpkernel.org/
As far as I figured out, they use a very stripped down Linux distro called Alpine Linux as the base and then build a Docker image on top of that. How is this a hack? This just means you are now running Alpine Linux in your containers instead of your distro of choice which nobody really wants.
Yeah, except that FreeBSD has had 'jails' for over a decade, which are far more secure than anything Docker brings to bear.
Linux has had jails for over a decade. I image that FreeBSD actually goes back further than that.
Docker has jails plus virtual networks plus various other isolation mechanisms, so I cannot credit your assertion that a jail-only mechanism is more secure.
"Linux has had jails for over a decade. I image that FreeBSD actually goes back further than that."
Yep, jails appeared in FreeBSD 4.0-RELEASE around 1999-2000 if I recall correctly.
"Docker has jails plus virtual networks plus various other isolation mechanisms, so I cannot credit your assertion that a jail-only mechanism is more secure."
To be fair, FreeBSD also has virtual networks so each jail can also run a complete virtualized network.
As for a comparison in security, I'm unable to make an informed comment.
"Linux has had jails for over a decade. I image that FreeBSD actually goes back further than that."
Yep, jails appeared in FreeBSD 4.0-RELEASE around 1999-2000 if I recall correctly.
"Docker has jails plus virtual networks plus various other isolation mechanisms, so I cannot credit your assertion that a jail-only mechanism is more secure."
To be fair, FreeBSD also has virtual networks so each jail can also run a complete virtualized network.
As for a comparison in security, I'm unable to make an informed comment.
FreeBSD jails appeared 2000 and had root privilege isolation. The only missing part would be IO rate limiting and root privilege isolation appeared on Linux with OpenVZ (2005). From personal experience with jails and docker: I prefer the jail networking and configuration. The benefit of docker is the online repo.
I read this yesterday and I found it slightly annoying in the tone. Alpine has been around for awhile, and I don't think anyone using docker for more than experimentation will be happy with massive Ubuntu based images. But would you really use these minimal images packaged by an unknown entity when you can make your own with one line in the dockerfile?
Image size is actually one recurring concern of Docker users. One problem being that when you build an image, every build step will be persisted in a layer (like a incremental snapshot of you container), and those layers can be cached and reused when building other docker images.
Now, the drawback is that if you have an intermediate build step where, for example, a huge set of temporary files were created, then those files will also be persisted in your local Docker registry. In some case, when pulling a single image you will need to fetch layers which will sum up to N times the actual size of the container without being ever reused again. Not great.
Beyond being a simple annoyance, this has a security implication too. For example, when building the image imply storing in an intermediate layer some kind of secret (private key, password, etc).
There are some workaround available. You may either keep the number of individual build step down by chaining interpreter commands or relying on additional shell scripts. There are also hacks available to trim the layers from an image, up to a single layer (to end with a "flat" image). But those are only hacks and people really would like to see something implemented directly in the Dockerfile syntax. Several issues has been filled (eg. https://github.com/docker/docker/issues/332) but none of them were able to reach a consensus on how this should be done while preserving backward compatibility and the caching system.
Disk usage problems also affects private registries, especially since, as the Version 2 of the registry implementation, there is currently no straightforward way to delete a stored image (due to integrity reasons with the distributed storage drivers).
Dangling Docker volumes (that are not tied to a container any more) may also easily fill up your hard drive if you do not pay attention. But the situation slightly improved with recent version of Docker and the ability to track such volume down.
I wondered this too... and why they are pointing to Alpine's "Edge" specifically.
From the Alpine Distro's page:
Warning: "edge" is under constant development so be careful using it in production. It is possible that bugs in "edge" could cause data loss or could break your system.
You can run Docker on FreeBSD thanks to the 64-bit Linux compatibility layer that was added last year.
FreeBSD Jails and Linux Containers are really different beasts. Jails are great if security is your primary consideration. Hence the name: Jails effectively isolate processes and go to great lengths to prevent them from accessing anything outside the jail. Containers use separate kernel namespaces to give groups of processes separate views of kernel global variables. Security (especially with user namespaces) is a bonus, but the primary goal is efficient os-level virtualization and isolation of resources. A more apt comparison is with the BSD VPS project rather than Jails.
At a guess the jail support didn't make it.
Correct. XNU does not have support for Jails, and it likely won't because it requires some pretty severe changes to kernel data structures to make them work.