Secure Your Container Data With Ephemeral Docker VolumesWhat with all the furore 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 we'll have a quick look at now.
The 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 no doubt 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 One 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 One: 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
For the aforementioned versioning reasons noted above I will caveat the following with a note that even though the feature below might not work exactly as you expect it to hopefully the concepts will 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 however but what if you needed to save data of some sorts which your container had 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, e-mails 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-ce for reference).
$ docker run -d --read-only -it --mount type=tmpfs,destination=/var/tmp nginx
In Figure Two 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 Two: 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 though 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:
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.
If you've enjoyed reading the technical content on this site then please have a look at my Linux books which were both published in 2016 and some of my articles in Linux Magazine and Admin Magazine are available on their respective websites.