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..."
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
As a developer, I though the entire point of Docker was to reduce dependence on an entire layer of IT: the human gatekeepers in charge of the release systems and procedures and eventually the care and feeding of maintenance systems (who often f*** something up with manual fumbling or delay things with meetings involving coffee-swilling waterbags).
At least that's how I've seen Docker used in corporations so far, anyway.
iocage create -c
Congratulations, you've just (almost) caught up to decade old technology.
http://phk.freebsd.dk/pubs/san...
That should be the new vulnerability metric. Womp rats.
"A new vulnerability was found in the D-Star app this week, rating at 3.8 womp rats. CEO Tarkin downplayed the severity of the vulnerability and promised the D-Star app will continue to enhance system stability without interference from any rogue squadrons of hackers."
I don't suffer from insanity, I enjoy every minute of it!
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?
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
"Less code/less programs in the container means less attack surface..."
Inheritance is the sincerest form of nepotism.
https://www.youtube.com/watch?...
Wasn't a common library the entire point of Docker?
Packaging the libs with the app, etc, to reduce dependence on the host OS?
No, although it's one of Docker's features. Docker images are actually stacked layers of filesystem sub-images operating as overlays, so a typical Docker image might consist of a base OS image, several library images built by the Docker build process, culminating in the actual application image. Done judiciously, those sub-images can be shared by multiple application images, thereby saving space in the Docker image store.
But Docker is a lot more than that. You can run virtual networks within containers, share resources between selected containers (and ONLY those container), inject external filesystems into the containers and do many other useful things as well.
Docker containers don't contain a kernel. They use the host OS for services.
The problem with your logic (aside from being irrelevant in the case of Docker since it doesn't include a kernel) is that a lot of the "cruft" has been added as a base requirement to make a bootable modern system, and in many cases to improve performance.
You can strip everything back to 20 years ago, but will you be able to run your harddrives in PIO mode 2 all for the sake of making the kernel smaller by not needing UDMA support? Okay contrived example, but that's what I'm talking about. You want a small kernel, look at HURD. It should boot on a 64bit system sometime before 2020 and it maybe one day will get USB support.