Container Isolation is a Myth: Hardening Docker for Production in 2020

If you think a Docker container offers the same security boundary as a Virtual Machine, you are going to have a bad year. February's runc vulnerability (CVE-2019-5736) was a wake-up call for the entire industry. We saw how easily a malicious container could overwrite the host runc binary and gain root execution on the host machine. If you were running unpatched Docker versions on a shared kernel without strict isolation layers, you were exposed.

As we head into 2020, "default" configurations are no longer acceptable. I’ve spent the last six months auditing Kubernetes clusters across Oslo, and the pattern is terrifying: containers running as root, full capability sets granted to web parsers, and sensitive customer data mounted on ephemeral volumes without encryption.

Here is how we lock this down. No fluff, just the configs that stop attackers.

1. The Root Problem (Literally)

The most common mistake I see in Dockerfile audits is the absence of a USER instruction. By default, processes inside the container run as root. If an attacker compromises that process (via a buffer overflow in your application, for instance), they are root inside the container. If they then hit a kernel vulnerability, they are root on your server.

Stop doing this. Create a specific user for your application.

The Fix:

FROM alpine:3.10

# Create a group and user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Install dependencies
RUN apk add --no-cache python3

# Switch to non-root user
USER appuser

WORKDIR /home/appuser
COPY . .

CMD ["python3", "app.py"]

Pro Tip: In 2019, Alpine is still the king of small attack surfaces, but keep an eye on "Distroless" images from Google. They strip even the shell, making debugging harder but persistence a nightmare for attackers.

2. Drop Capabilities like Hot Potatoes

The Linux kernel divides root privileges into distinct units called capabilities. Does your Nginx container need to tweak system clocks (`CAP_SYS_TIME`)? Absolutely not. Does your Node.js app need to load kernel modules (`CAP_SYS_MODULE`)? Never.

Docker grants a broad set of capabilities by default. You should start by dropping all of them and adding back only what is strictly necessary.

docker run --d -p 80:80 \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --name web-server \
  nginx:alpine

If you are orchestrating with Kubernetes (1.16 is solid right now), you enforce this via Pod Security Policies (PSP). This is mandatory if you are operating in a multi-tenant environment.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  # Prevent changing user ID to root
  runAsUser:
    rule: 'MustRunAsNonRoot'
  # Drop all capabilities
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'secret'
  hostNetwork: false
  hostIPC: false
  hostPID: false

3. Read-Only Filesystems

If an attacker gets a shell, their first move is to download a payload or modify a config file. Make their life miserable by mounting the container's root filesystem as read-only. Applications should only write to specific, mounted volumes for logs or temp data.

This single flag eliminates an entire class of persistence vectors:

docker run --read-only \
  --tmpfs /run \
  --tmpfs /tmp \
  -v /var/log/app:/var/log/app \
  my-secure-image

4. Infrastructure Matters: The Noise and the Law

Software hardening is useless if the hardware underneath is compromised or oversubscribed. In the Nordic market, we face a specific challenge: Data Residency. With the GDPR in full swing and the US Privacy Shield framework looking increasingly shaky (legal experts are already flagging risks with US cloud providers), keeping data on Norwegian soil is not just about latency—it's about compliance.

Furthermore, running containers requires high I/O throughput. If your "noisy neighbor" on a cheap VPS is mining cryptocurrency, your Docker builds will stall, and your database containers will time out.

The KVM Advantage

This is where we draw the line at CoolVDS. We don't use container-based virtualization (like OpenVZ) for our VPS nodes because it shares the kernel directly. We use KVM (Kernel-based Virtual Machine). This provides a hardware-level virtualization boundary.

For high-performance Docker hosts, disk I/O is usually the bottleneck. Layering a filesystem (Overlay2) on top of a virtual disk requires speed. Our infrastructure uses pure NVMe storage arrays. When you run docker-compose up on a Magento stack, the difference between standard SSD and our NVMe tiers is the difference between a 30-second deploy and a 5-second deploy.

5. Network Segmentation and Local Latency

Don't expose the Docker daemon socket (`/var/run/docker.sock`) to the outside world. Just don't. If you need remote management, use SSH with keys.

For those of you serving the Norwegian market, latency to the NIX (Norwegian Internet Exchange) is critical. If your API containers are chatting with a database, every millisecond of round-trip time (RTT) compounds. Hosting in Frankfurt or London adds 20-30ms. Hosting in Oslo reduces this to <2ms. This isn't just user experience; it's SEO, especially with Google's increasing focus on page speed metrics.

Implementation Checklist

1. Audit Images: Use a scanner like Clair or Anchore Engine in your CI pipeline. If it has high-severity CVEs, block the build.
2. Limit Resources: Always set memory and CPU limits. A memory leak in one container shouldn't crash the whole server.
   --memory="512m" --cpus="1.0"
3. Use Private Networks: Connect containers via user-defined bridges, not the default bridge. This provides automatic DNS resolution and better isolation.

Security is a process, not a product. But starting with a solid foundation—hardened configurations on top of isolated KVM infrastructure—gives you a fighting chance against the threats we are seeing evolve in late 2019.

Need a sandbox to test these configs? Deploy a KVM-based, NVMe-powered instance on CoolVDS today. We offer native DDoS protection and low-latency connectivity to the Norwegian backbone, ensuring your containers stay fast and compliant.