Docker in Production: Security Survival Guide for the Paranoia-Prone

Let’s be honest: Docker is eating the world. I’ve seen more transition plans in the last six months than I have in the last six years combined. But while everyone is high-fiving over sub-second deployment times, I’m the guy in the corner sweating bullets about the kernel.

The uncomfortable truth about September 2015? Most of you are running containers as root. You are pulling images from the Docker Hub without verifying signatures. You are effectively handing the keys to your infrastructure to a random maintainer named "xX_DevOps_Ninja_Xx".

I recently audited a setup for a client in Oslo—a sharp team, cutting edge. They had mounted /var/run/docker.sock into a Jenkins container exposed to the web. One remote execution vulnerability later, and the attacker wouldn't just have the container; they would own the host. Game over.

If you are deploying containers on bare metal or shared kernels, stop. If you are doing it right, you are wrapping them in the iron-clad isolation of KVM. That’s why we built the CoolVDS platform on pure KVM—because cgroups are not a security boundary.

1. The Root of All Evil (and How to Drop It)

By default, the process inside the container runs as root. If that process breaks out (and kernel exploits happen), it is root on your host. The simplest fix? Don't be root.

When writing your Dockerfile, create a user. It adds two lines and sleeps better than Ambien.

RUN groupadd -r app && useradd -r -g app app
USER app

If you are stuck with a legacy image that demands root, you can at least neuter it at runtime. Docker 1.6+ gave us the ability to drop capabilities. Does your Nginx container really need to change system time or load kernel modules? No.

Run it like this:

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx

2. Immutable Infrastructure: Read-Only Filesystems

We talk about "immutable infrastructure," but then we let apps write logs, temp files, and who knows what else all over the container filesystem. If an attacker compromises your web app, the first thing they want to do is download a payload or modify a binary.

Make it impossible. Force the container to be read-only.

docker run --read-only -v /my/data:/data:rw my-app

With this flag, the root filesystem is immutable. You explicitly whitelist the directories that need write access using volumes. This forces a discipline that many devs hate, but your SysAdmin will love.

Pro Tip from the Trenches:
Combining --read-only with the new Docker Content Trust (introduced in 1.8) is the gold standard. Export DOCKER_CONTENT_TRUST=1 in your shell before pulling. It ensures the bits you run are actually the bits the author pushed. No man-in-the-middle attacks injecting malware into your base images.

3. The "Noisy Neighbor" & Shared Kernel Problem

Here is where the "Pragmatic CTO" and I agree. Containers share the host kernel. If a kernel panic occurs inside a container, the whole ship goes down. In a multi-tenant environment, this is terrifying.

This is why pure container hosting services make me nervous for critical data. They rely heavily on namespaces and cgroups to keep customers apart. Historically, these have been leaky.

The CoolVDS Architecture:

We take a different approach. We don't sell you a container; we sell you a KVM (Kernel-based Virtual Machine) slice. You get your own kernel.

If you want to run Docker, run it inside a CoolVDS instance. If one of your containers goes rogue, it crashes your VM, not the physical node. Plus, with our NVMe storage backend, the I/O overhead of virtualization is negligible compared to the safety gains.

4. Data Sovereignty and the Norwegian Context

We are waiting to see what happens with Safe Harbor, but the writing is on the wall: European data needs to stay in Europe. Datatilsynet (The Norwegian Data Protection Authority) is not known for being lenient.

When you spin up a container on a massive US cloud provider, do you know exactly where that volume lives? Is it replicated to a backup center in Virginia? With CoolVDS, your data sits in our Oslo data center. The latency to NIX (Norwegian Internet Exchange) is practically a rounding error, and the legal jurisdiction is clear.

5. Network Segmentation

Don't use the default bridge network for everything. Since Docker 1.9 isn't out yet (rumor has it networking is getting a huge overhaul soon), we have to be smart with links and legacy networking.

Do not publish ports (-p 80:80) unless absolutely necessary. If you have a database container, do not expose it to the host interface. Use container linking or, better yet, set up a VPN mesh like Tinc or Weave if you are spanning multiple hosts. Keep your database purely internal.

Final Thoughts

Security is a process, not a product. But starting with the right foundation makes the process a hell of a lot easier. Lock down your user permissions, verify your images, and for the love of uptime, put your Docker hosts on dedicated KVM virtualization.

Need a sandbox to test these flags without risking your production rig? Deploy a CoolVDS instance in 55 seconds. It’s cheap insurance against a kernel panic.