Whoever designed Docker and containers clearly wasn’t responsible for InfoSec – a rant

May 12, 2016

Not just recently I’ve been trying to get a grasp of all the containerization hype and try to identify possible effects on the ways I see to do certain things. I’m reluctant to use the word “operations” here because I’m not really much of an “operations guy” in the sense of actually having ongoing responsibility for a significant number of machines, doing monitoring, getting woken up by a pager etc. I do however have enough administration experience on a small scale to be able to tell which ideas could work and which ideas clearly won’t, at least in the near time. I’m not going to draw the dividing line between “ops” and “devs” here once again, that topic has been bashed about enough for a long time.

Thinking about containerization there are some questions that come up in my mind that demand for answers, paired with the surprised observation that many others seem not to have identified these questions as important enough to be considered. These are questions about single fields such as building and running but also about the larger picture of a combined workflow.

One of these questions is the one of updates. Remember the dark ages before Linux distributions became popular, when we grabbed and compiled software ourselves? Back then the main reasons were that you actually had to go collect all that software over slow links and what not, get the dependencies right and compilation literally took days.

Nowadays it seems en vogue to bash on distributions ([1], [2], [3]). Some distributions (eg. Debian) are said to ship “outdated” software only and addressing different distributions and their differences has become that much of a pain apparently that solutions such as FPM and Omnibus turned up, allowing them to just do the job themselves and ship what used to be system components such as OpenSSL.

Containers are not a direct children of this movement but they unquestionably bear some of the same implications. Containers as seen with Docker et al. basically reflect compiled executables: there is a source (the Dockerfile) and a generated binary (the container image) that can not be regenerated without the source. Meaning that without access to that source, the container image can not be rebuilt.

Now if I were an Ops guy, I would not sweat that much when another OpenSSL update is being released. After all, deploying updates would be part of my daily job. I would sweat if I were responsible for minimizing the attack surface in my company and see that a particular vulnerability is fixed. In the past, responsibilities were clearly divided in that the Ops guys took care of the base distribution and apply security fixes. Yes, always assuming that this would not break the application which, in my naiveness, I assume to hold true for most security fixes (otherwise kick your local $DISTRO account manager).

Nowadays I can’t rebuild the container to include the security fix unless I get access to the Dockerfile. Yes, I could generate a new image based on that image but that sort of defeats one of the core ideas of the containerization movement, rebuilding container images instead of granting them a maintenance lifecycle of their own (“cattle, not pets”).

And the problem actually gets more complex than with the “One big fat RPM to rule them all” concept because containers can build upon other containers. So if I rebuild my base container image, I have to deduce what others containers depend on that base image and rebuild them as well.

You would think that there were a possibility to get the dependencies of your local container images nicely laid out. Well, there was: docker images viz, but guess what? That was considered deprecated and removed in newer Docker versions. Nowadays you’d have to run a special container image to get what could be considered essential management functionality. Yay for Docker!

So eventually it turns out (and yes, I know many of you already knew that) that Docker by itself at least is fine for development. But not for real-world production scenarios. And no, CoreOS, Mesos, Kubernetes et al. won’t help me here either. All I’m trying is to solve the “how to keep my containers up-to-date” Problem on a single node!

Tags: , ,
Posted in Containers, Docker by Pieter Hollants

 
Copyright © 2020 by Pieter Hollants. All rights reserved. - Legal notices & Privacy policy