The Container Hype vs. The Root Exploit Reality
It has been a rough month for anyone with a public-facing IP address. Late September gave us Shellshock, a Bash vulnerability that made us all look at our patching scripts with fresh paranoia. Now, as teams across Oslo and Europe rush to adopt Docker 1.2 to simplify deployment pipelines, I am seeing a terrifying trend: developers treating containers as if they are fully isolated virtual machines. They are not.
Let's be brutally honest. A container is effectively a fancy chroot with some kernel namespaces and cgroups sprinkled on top. If you run a process as root inside a container, and that process escapes the namespace (which happens more often than the Docker marketing team admits), you have just handed root access of your host node to an attacker. In a shared hosting environment, that is catastrophic.
The "Privileged" Trap
The most dangerous flag in the Docker CLI today is --privileged. I see developers using it to fix permission errors or to mount devices. Stop it. When you run a container in privileged mode, you are essentially disabling the few safety mechanisms Docker provides.
Instead of giving the container the keys to the castle, you should be explicitly dropping capabilities. The Linux kernel breaks down root privileges into distinct units. Does your Nginx container really need CAP_SYS_ADMIN or CAP_NET_ADMIN? Absolutely not.
Here is how you should be running a web service in 2014, stripping it of everything it doesn't need:
docker run -d \
--name=frontend_app \
--cap-drop=ALL \
--cap-add=NET_BIND_SERVICE \
--cap-add=SETUID \
--cap-add=SETGID \
-p 80:80 \
coolvds/nginx-custom:1.6By using --cap-drop=ALL and only adding back what is strictly necessary, you reduce the attack surface by 90%. Even if an attacker exploits a vulnerability in the web server code, they find themselves in a sandbox with no tools to break out.
The Filesystem is Your Enemy
Another rookie mistake I see in audits involves the AUFS or DeviceMapper storage drivers. Developers leave the root filesystem writable. This allows an attacker to overwrite system binaries or inject malicious scripts that persist if the container is restarted (though, ideally, your containers are immutable).
Make your containers read-only by default. Force your application to write only to specific, mounted volumes. This is basic hygiene.
docker run --read-only -v /var/log/app:/app/logs my-appPro Tip from the Trenches: If you are running high-I/O databases like MySQL or PostgreSQL in containers, verify your backing filesystem. The default loopback device setup in Docker can kill performance. On CoolVDS, we recommend mounting our NVMe storage directly into the container as a data volume to bypass the Copy-on-Write overhead entirely.
Network Isolation and the "Localhost" Fallacy
By default, Docker bridges containers to the host network. If you aren't careful with your iptables, you might be exposing internal management ports to the public internet. I recently saw a MongoDB instance exposed to the world because the developer assumed binding to 0.0.0.0 inside the container was safe as long as they didn't map the port. They were wrong.
Always bind specific interfaces. If you are hosting on a VPS in Norway to serve local traffic, bind your services to your private LAN IP for internal communication, not the public interface.
Check your NAT table manually. Don't trust the daemon to get it right:
iptables -t nat -L -n -v
Chain POSTROUTING (policy ACCEPT 42 packets, 2500 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0Why KVM Still Matters (The CoolVDS Architecture)
This brings us to the infrastructure layer. There is a debate raging right now about running containers on bare metal versus running them inside Virtual Machines. For a private data center you own, bare metal is fine. For anything facing the public internet or running in a multi-tenant cloud, you need a hypervisor.
Containers share the host kernel. If a kernel panic occurs in one container, the whole ship goes down. This is why at CoolVDS, we strictly use KVM (Kernel-based Virtual Machine) for our instances. KVM provides hardware-level virtualization.
When you spin up a VPS with us, you get your own dedicated kernel. You can run Docker, LXC, or OpenVZ inside your CoolVDS instance, and if you manage to crash the kernel, only your VPS reboots. Your noisy neighbor cannot access your memory segments, and more importantly, Datatilsynet (The Norwegian Data Protection Authority) will be much happier knowing your customer data is separated by a hypervisor, not just a namespace.
Configuration Checklist for Production
| Risk Area | Docker Setting | CoolVDS Recommended Action |
|---|---|---|
| Kernel Exploits | --cap-drop=ALL |
Use KVM virtualization for hardware isolation. |
| Data Persistence | -v /host:/container |
Use dedicated block storage mounts for DBs. |
| Resource Denial | --memory=512m |
Rely on VDS resource limits to prevent CPU stealing. |
Managing Secrets (Before It Was Easy)
We don't have a standardized "vault" solution in the ecosystem yet. I see developers hardcoding API keys into Dockerfile ENV vars. This is visible to anyone running docker inspect. Don't do it.
Until we have better orchestration tools, the safest method is mapping a read-only volume containing a config file that is injected at runtime, or populating environment variables from a secure source on the host during the docker run command.
# A cleaner approach for 2014
cat secret.env | xargs -I {} docker run -e {} my-secure-appFinal Thoughts: Latency and Laws
Security isn't just about hackers; it's about reliability and compliance. Norway has strict privacy standards under the Personal Data Act. Hosting your data outside the country introduces legal latency and network latency.
If your users are in Oslo, routing traffic through a budget host in Frankfurt adds unnecessary milliseconds. CoolVDS offers low-latency, NVMe-backed storage located directly in Norwegian data centers. You get the speed of containers with the security of a fortress.
Don't wait for the next Heartbleed or Shellshock to audit your infrastructure. Secure your kernel, drop your capabilities, and host on hardware that respects your need for isolation.
Need a sandbox to test your hardened Docker configs? Deploy a KVM instance on CoolVDS in under 55 seconds.