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
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.