Docker in Production? Not Without These 5 Kernel Hardening Strategies

It has been a wild year for those of us in the trenches. Since Docker 1.0 dropped earlier this summer, every developer I know wants to ship containers. I get it. The portability is incredible. But as a Systems Architect responsible for keeping data secure in Oslo, the current state of container security keeps me up at night.

Let’s be honest: Containers do not contain. Not yet, anyway.

Unlike the KVM virtualization we rely on for our CoolVDS instances, Docker containers share the host kernel. If a process inside a container manages to exploit a kernel vulnerability—and after the Shellshock mess in September, we know those exist—they own the host. They own the ring 0. Game over.

Does this mean you shouldn't use Docker? No. It means you need to stop trusting default configurations. If you are deploying to production today, you need to harden the hell out of that runtime. Here is how we are doing it securely in late 2014.

1. The "Root" Problem and User Namespaces

By default, if you are root inside the container, you are root on the host. This is terrifying. If an attacker breaks out of the cgroup jail, they have full administrative privileges over your server.

The Linux kernel community is working hard on User Namespaces, but support in Docker is still experimental and tricky to configure right now. Until this matures, do not run services as root inside your Dockerfiles.

# BAD PRACTICE
FROM ubuntu:14.04
CMD ["/bin/my-service"]

# GOOD PRACTICE
FROM ubuntu:14.04
RUN groupadd -r app && useradd -r -g app app
USER app
CMD ["/bin/my-service"]

It sounds simple, yet I see 90% of images on Docker Hub ignoring this. Don't be that guy.

2. Drop Linux Capabilities

The Linux kernel breaks down "root" privileges into distinct units called capabilities. A web server does not need to load kernel modules or change the system time. Yet, by default, Docker gives containers a wide array of these dangerous permissions.

We need to adopt a "deny all, permit some" approach. Use the --cap-drop and --cap-add flags introduced recently.

For a standard Nginx web server, you can drop almost everything:

docker run -d \
  --name secure-nginx \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --cap-add=SETUID \
  --cap-add=SETGID \
  nginx:latest

This ensures that even if the Nginx process is compromised, the attacker cannot modify network routes (NET_ADMIN) or mount filesystems (SYS_ADMIN).

3. Kernel Isolation: KVM is Your Safety Net

This is where infrastructure choice becomes a security feature. In the shared hosting world, or with older container technologies like OpenVZ, you are at the mercy of the provider's kernel. If they don't patch a vulnerability, you are exposed. Worse, your neighbors might crash the kernel you are running on.

At CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine) for our VPS nodes. This gives you a dedicated kernel.

Architect's Note: The safest way to run Docker in 2014 is inside a KVM VPS. You get the developer convenience of containers, wrapped in the hardware-level isolation of virtualization. If a container escapes, it only hits your VPS kernel, not the bare metal host managed by us.

This double-layer encapsulation is critical for compliance with the Norwegian Personopplysningsloven (Personal Data Act). You cannot claim to have adequate separation of data if a shared kernel bug allows memory scraping between tenants.

4. Filesystem Read-Only Mode

Immutability is a buzzword, but it works. If your application is stateless (as it should be), it doesn't need to write to the container's filesystem. Mount the root filesystem as read-only.

docker run --read-only -v /var/log/myapp:/var/log/myapp -d my-app

If an attacker finds a remote code execution vulnerability, they can't download a backdoor script or modify system binaries because the disk won't let them write. It forces you to be disciplined about where you store persistent data—which should be on mounted volumes, ideally backed by our high-performance storage arrays.

5. Network Segmentation with Iptables

Docker's default bridge network allows all containers to talk to each other. If your frontend container gets hacked, it can scan your database container on the internal network.

Until we get more advanced orchestration tools (Google is talking about something called Kubernetes, but it's very alpha), we rely on good old iptables. By setting --icc=false (Inter-Container Communication) in your Docker daemon configuration, you force containers to be isolated by default.

Edit your /etc/default/docker (on Ubuntu 14.04):

DOCKER_OPTS="--icc=false --iptables=true"

Then, explicitly link containers only when necessary using the --link flag. This creates a whitelist approach to internal traffic.

The Performance Impact

Security usually costs performance. However, because KVM passes instructions directly to the CPU, and Docker uses native syscalls, the overhead is negligible. We recently benchmarked a MySQL container running on a CoolVDS SSD instance versus a bare-metal install.

The difference is imperceptible for 99% of web applications, but the security gain of the KVM wrapper is massive.

Conclusion

We are still in the early days of containerization. Tools are evolving weekly. But the fundamentals of Linux security—least privilege, isolation, and segmentation—haven't changed.

Don't just docker run and pray. Drop those capabilities. Isolate your networks. And most importantly, run your container clusters on infrastructure that respects tenant isolation. With the Data Protection Authority (Datatilsynet) keeping a close eye on data handling here in Norway, "I didn't know" is not a valid legal defense.

Need a sandbox to test your hardened Docker configs? Deploy a CoolVDS NVMe instance in Oslo today. You get full root access, a dedicated kernel, and the low latency you need for serious development.