What with all the furor around containers and orchestrators, it can be easy to lose sight of some of their highly useful features. The portability and extensible nature of containers is a modern convenience to be cherished, but from my professional perspective it’s sometimes all too easy to get carried away and pay less attention to security.
There’s a lesser-known feature in the venerable Docker that I like using from a security perspective, which I’ll take a quick look at now.
Ye olde feature I have in mind has been around for a whopping 20 months at the time of writing. Believe me when I say that’s a millennium when it comes to containers, which have evolved their feature-sets at hyperspeed. From Docker version 1.10, it’s been possible to run your containers with a temporary storage, or temporary volume mount to be more precise. From the release notes of Docker v1.10, we can see the feature announcement as described below as follows:
“Temporary filesystems: It’s now really easy to create temporary filesystems by passing the –tmpfs flag to docker run. This is particularly useful for running a container with a read-only root filesystem when the piece of software inside the container expects to be able to write to certain locations on disk.”
In Figure 1, we can see the key difference between temporary and standard volumes. If you’re interested in some of the discussions around the naming of the temporary filesystem feature, then there’s some chatter available on one of Moby’s GitHub repositories.
Figure 1: Temporary filesystems are written to RAM (or to your swap file if RAM is filling up) and not to the host or the container’s own filesystem layer at Docker.com: Docker tmpfs. (Image: Docker)
For the aforementioned versioning reason, I will caveat the following with a note that, even though the feature below might not work exactly as you expect it to, the concepts should help you to flex your lateral-thinking muscles nonetheless. In other words, check your Docker runtime version and its accompanying docs in case there’s a syntax change or the feature has been deprecated or enhanced in some way. We will see in a moment that there’s more than one way to mount a temporary volume, for example.
Let’s have a look at putting this feature to good use. Consider a scenario where you had a container ticking over nicely in read-only mode. You chose to do this because you were aware that for security reasons it helped prevent any successful attacks, which compromised your container, persisting after it had been stopped and then restarted. In other words, your container was quite happy to save any relevant session data internally but not commit any actual changes to its original files, because it used the –read-only option when it was started up.
That configuration is ideal for many purposes, but what if you need to save data of some sort that your container has captured? For simplicity, let’s imagine that your container was running a website and you captured visitor data through a form on the site. You know the sort I mean I’m sure: a few input HTML boxes, a pull-down menu, and a radio button here or there, all presented nicely with a sprinkling of CSS.
To store your captured data, you have a handful of options. We will leave databases, emails, and message brokers aside and aim more along the lines of writing our captured data to disk.
In standard Docker terms, there’s an obvious way of achieving this namely by creating a standard volume and mounting it to a directory on your host machine. For example, /home/chrisbinnie/storage on my host might be /storage inside my container.
However what if you were running a whole heap of similar containers and you didn’t want the data to get mixed up in the directory on the host? Or, you didn’t need the data to be available for long or even that you were worried that it could contain unwelcome, dangerous code because the big, bad Internet had submitted the data.
Thankfully, Docker thought about our quandary in advance and provides exactly what you need in the form of ephemeral, or short-lived, volumes. Incidentally, I’ve heard called this very option called volatile volumes too in the past.The best bit from a security standpoint is that when your container stops your ephemeral volume just automatically disappears into the ether along with your (un)saved data.
Let’s have a look at the command syntax required to get this working (my current runtime version is 17.06.2-cefor reference).
$ docker run -d --read-only -it --mount type=tmpfs,destination=/var/tmp nginx
In Figure 2, we can receive some welcome news having run a $ docker inspect d7c0c command (I have abbreviated the container’s hash, replace it with your container ID).
Figure 2: A temporary read/write volume pointing at our container’s innards.
Another way of running this command is the more concise –tmpfs option as shown below. This doesn’t allow additional options in quite the same way, however.
$ docker run -d --read-only -it --tmpfs /var/tmp nginx
We can also chuck in — sorry, I mean “enhance” — our useful feature with a few other sophisticated options by following the –mount option in the man pages as so:
type=tmpfs,tmpfs-size=512M,destination=/path/in/container
If you’re struggling to find the right detail within man pages, then simply use this command and search for “tmpfs” in lowercase:
$ man docker run
As we’ve seen, there’s a host of features which help pump Docker’s pistons and many are easy to forget or can be simply missed due to the vast number available. I hope you can put temporary volumes to good use in one form or another in the future. You can store a variety of different types of data to disk and even tiny files such as one-off, time-limited passwords which might be required to allow a container to instantiate an external service.
Learn more about essential sysadmin skills: Download the Future Proof Your SysAdmin Career ebook now.
Chris Binnie’s latest book, Linux Server Security: Hack and Defend, shows how hackers launch sophisticated attacks to compromise servers, steal data, and crack complex passwords, so you can learn how to defend against these attacks. In the book, he also talks you through making your servers invisible, performing penetration testing, and mitigating unwelcome attacks. You can find out more about DevSecOps and Linux security via his website (http://www.devsecops.cc).
