Docker in Production: Security Strategies Before You Ship

The "It Works on My Machine" Trap

We need to have a serious talk about Docker. By now, half of the developers in Oslo are pushing for it, and for good reason. It solves the dependency hell that has plagued us since the early days of RHEL 5. But as a SysAdmin who has spent too many nights fixing "quick fixes," I see a dangerous trend emerging in 2015.

Devs are pushing containers to production with default settings. And default Docker settings are, to put it mildly, optimistic about security. Unlike a traditional VPS where the hypervisor provides a hard hardware abstraction layer, a container shares the host kernel. If you exploit a kernel vulnerability inside a container, you own the host.

In this guide, we aren't discussing theory. We are looking at hard configurations to lock down your Docker 1.7+ instances running on Ubuntu 14.04 or CentOS 7. Whether you are hosting a startup app or a Magento shop, these rules apply.

1. The Root Problem (Literally)

By default, the process inside the container runs as root. If that process breaks out (via a kernel exploit like Shockbuster or similar future threats), it has root on your server. I saw a setup last week where a developer mounted /var/run/docker.sock into a container to run Jenkins. That is effectively giving the container sudo access to the host.

The Fix: Force a non-privileged user in your Dockerfile. Do not rely on runtime flags alone.

If you absolutely must run as root (some legacy AMP stacks require it), you need to lean heavily on capabilities restrictions.

2. Drop Linux Capabilities

Linux divides root privileges into distinct units called capabilities. A web server doesn't need to mount filesystems or load kernel modules. Yet, by default, Docker gives it those permissions.

Use the --cap-drop flag to strip everything, then add back only what you need. This is the principle of least privilege applied to the kernel.

This command ensures that even if an attacker compromises Nginx, they can't change system time or modify kernel parameters. It stops most privilege escalation attacks dead in their tracks.

3. The Storage Driver Bottleneck

Security isn't just about hackers; it's about availability. In 2015, the default DeviceMapper setup on CentOS 7 loop-lvm is a performance killer and a stability risk. Under heavy I/O load, I've seen the Docker daemon hang completely, requiring a hard reboot.

Pro Tip: If you are running on CoolVDS, our underlying storage is pure NVMe. Do not use the default loopback DeviceMapper. Configure overlayfs (if on kernel 3.18+) or direct LVM for stability. Your I/O wait should be near zero.

4. Network Isolation and Norwegian Compliance

The default docker0 bridge allows all containers to talk to each other. If your Redis container gets compromised, can it sniff traffic from your MySQL container? On the default bridge, yes.

Link your containers explicitly or, better yet, use the new experimental networking features surfacing in Docker 1.7 to create isolated networks. This is crucial for compliance with the Norwegian Personal Data Act (Personopplysningsloven). Data segregation is a legal requirement here, not just a technical nice-to-have. If you are storing customer data, Datatilsynet expects you to prove that your architecture prevents lateral movement.

5. Why We Still Use KVM at CoolVDS

You might ask, "If containers are so efficient, why does CoolVDS sell KVM (Kernel-based Virtual Machine) VPS?"

The answer is isolation. Containers are great for application packaging, but they are not a security boundary I trust 100% yet. The "noisy neighbor" effect is real. In a shared kernel environment (like OpenVZ or bare-metal container hosting), one user's fork bomb is your downtime.

At CoolVDS, we wrap your Docker environment in a KVM slice. You get:

• Dedicated Kernel: Tune your sysctl.conf without asking permission.
• Hard Hardware Virtualization: No noisy neighbors stealing CPU cycles.
• Data Sovereignty: Your data stays on disks physically located in Oslo, ensuring low latency to NIX and compliance with local laws.

If you are building the next big thing, use Docker for your code, but run it on a real hypervisor. The 2ms latency reduction you get from bare metal isn't worth the security trade-off when KVM overhead is now negligible on modern hardware.

Final Check

Before you deploy this Friday (don't do that), run your image through a scanner or check the layers manually. Don't pull blind from the Docker Hub. Build your own base images. Security is a process, not a product.

Need a sandbox to test your confined containers? Spin up a CoolVDS NVMe instance in 55 seconds. It’s faster than your local vagrant box.