Richard Bucker

There Is a Place for Docker When Done Right

Posted at — May 16, 2020

First of all I have come to hate docker. At one time it was an interesting solution to a serious problem. The problem was essentially needing a consistent way to jail applications so that if compromised the rest of the host might remain safe. This, of course, meant many different types of protection from hosted services, disk space, memory, networking, secure vlan and so on.

Keep in mind that chroot and variations of jail have been around for a while but they suffer from a singular weakness. Where most chroot implementations are the same it’s where the rubber meets the road that the minutia will get you. For example, you may need to bind the /dev folder or at least a couple of devices into the chroot. If the application(s) uses DLLs then you’ll need them too. And while you can use ldd to identify the late loading there are others that are not identified in ldd like libnss-dns.

That’s just the beginning…

Right now I’m trying to deploy a project on ClearLinux and the applications shells out to sh and curl. When it calls curl it passes a hostname but because I’m not running a DNS server in the chroot’d space the curl command is failing. AND the last thing I want to do is deploy a bind server… thus increasing the attack surface area.

While I’m starting to add these services I am getting closer to a scratch docker instance. At the same time many OS vendors are moving to systemd and systemd offers an nspawn feature. But with many of the same chroot issues. And it’s expensive to start and restart.

The choices are:

The problem remains that docker tried to be all things and as a result has many attack vectors. The HUB being one and anything more than just a plain scratch container. More importantly the container filesystem just keeps on growing and regardless of the performance maintenance provides a devops load that may be unreasonable.

moving on…