Docker is Not a Security Strategy: Hardening Containers for Production

Let’s be honest: 2015 is the year of the container. We are seeing deployments shift from heavy Chef/Puppet manifests to Dockerfile commits at a rate that makes my head spin. But amidst the hype of immutable infrastructure, there is a dirty secret getting glossed over in READMEs everywhere: default Docker configurations are a security nightmare.

I recently audited a setup for a client in Oslo—a promising eCommerce startup. They were running their payment gateway microservices as root, inside containers, on a shared kernel. If a process escaped that container (and yes, exploits like shocker.c exist), the attacker would have root access to the host node. Game over.

Efficiency is meaningless if your data is compromised. Here is how we lock down containers without sacrificing the speed you deployed them for.

1. The "Root" of All Evil

By default, the user inside a Docker container is root. If you map a volume from the host to the container, that container has root-level read/write access to those files. It’s terrifying.

The quick fix? Stop writing Dockerfiles that assume root. Create a user.

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

However, legacy apps often scream if they aren't UID 0. If you must run as root, you have to strip the kernel capabilities. In Docker 1.6+, we gained fine-grained control over this. Don't just run the container. Limit what it can do.

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

This command drops all Linux capabilities (like chown, setuid, etc.) and adds back only what is strictly necessary (binding to a network port). It drastically reduces the blast radius if the container is breached.

2. Isolation: Containers vs. Virtual Machines

This is where infrastructure choices become critical. A container shares the kernel with the host. If you are running containers on a "Container-as-a-Service" platform where you don't control the hypervisor, you are trusting the provider's kernel patching speed with your life.

Pro Tip: Never rely on namespaces alone for multi-tenant isolation. They were designed for resource segmentation, not security boundaries.

This is why at CoolVDS, we refuse to sell "system containers" (like OpenVZ/LXC) as secure environments for high-risk data. We use KVM (Kernel-based Virtual Machine). When you spin up a CoolVDS instance, you get your own dedicated kernel.

The Architecture of Trust:
1. Hardware Node
2. KVM Hypervisor (Hard Isolation)
3. Your CoolVDS Instance (Your Kernel)
4. Docker Engine
5. Your App

Even if an attacker breaks out of the container, they remain trapped inside your KVM instance. They cannot touch the host node or other customers. For businesses dealing with Norwegian consumer data (under Personopplysningsloven), this layer of defense isn't optional; it's due diligence.

3. The Immutable Filesystem

If your container gets hacked, the attacker usually wants to download a payload or modify a config file. Make their life miserable by making the container read-only.

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

This forces you to be explicit about where data is written. Logs go to STDOUT (or a volume), data goes to a mounted volume, and the rest of the system is frozen. It’s annoying to set up initially, but it prevents 90% of persistence mechanisms used by script kiddies.

4. Network Localities and Latency

Security isn't just about hackers; it's about availability. Norway has specific challenges regarding connectivity. Routing traffic through Frankfurt to serve users in Bergen introduces unnecessary latency and potential legal headaches regarding data transit.

We have seen "cloud" providers route internal traffic over public interfaces, exposing internal APIs to the world. Always bind your internal services to localhost or a private network interface.

# Bad
EXPOSE 8080

# Good
docker run -p 127.0.0.1:8080:8080 my-internal-service

Furthermore, keep your data resident in Norway. With the scrutiny on Safe Harbor increasing, keeping your VDS physically located in Oslo ensures you aren't caught off guard by shifting EU regulations. Datatilsynet is strict, and having physical sovereignty over your storage aids compliance significantly.

Final Thoughts

Containers are the future, but they are currently the Wild West. Don't wait for Docker 2.0 to fix your security posture. Use KVM-backed infrastructure to wrap your containers in true isolation.

Need a sandbox to test these flags? Deploy a KVM instance on CoolVDS today. We offer pure NVMe storage and local peering at NIX (Norwegian Internet Exchange), so your secure containers run faster than bare metal elsewhere.