Container Security Post-Meltdown: Hardening Docker for GDPR in 2018

It has been exactly six weeks since the world woke up to Meltdown and Spectre. If you are responsible for infrastructure in Oslo or anywhere else in Europe, you haven't slept much since January. The illusion of perfect isolation on shared hardware was shattered, and for those of us running heavy container workloads, the panic was justified.

Containers are not Virtual Machines. They are processes lying to themselves about how much of the OS they own. When you run Docker on a shared kernel—especially on legacy virtualization tech like OpenVZ—you are trusting a thin layer of namespaces to protect your customer data from a noisy (or malicious) neighbor.

With GDPR enforcement starting May 25th, that level of trust is no longer a technical debt you can afford. The Norwegian Data Protection Authority (Datatilsynet) will not be impressed by your "agile workflow" if a kernel exploit leaks PII. Here is how we lock down containers in a hostile environment, using tools available right now in early 2018.

1. Stop Running as Root (Seriously)

By default, the process inside your container runs as root. If an attacker manages a container breakout (CVE-2016-5195 Dirty COW is still fresh in our memory), they are root on your host. Game over.

You need to enforce non-privileged users inside your Dockerfile. Don't just rely on runtime flags; bake it into the image.

FROM alpine:3.7

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

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

# Ownership transfer
RUN chown -R appuser:appgroup /var/lib/nginx

# Switch to user
USER appuser

CMD ["nginx", "-g", "daemon off;"]

When you deploy this on a CoolVDS instance, you add depth to your defense. Even if the container is breached, they hit a user-level wall. If they breach that, they hit the KVM hypervisor wall. That is two more layers than you get on standard shared hosting.

2. The "Read-Only" Doctrine

Mutable infrastructure is a liability. If a container gets compromised, the first thing a script does is pull down a crypto-miner or a reverse shell. If the filesystem is Read-Only, that script fails.

Use the --read-only flag when launching containers. You will need to mount tmpfs for directories that actually need to write data (like PID files or temporary caches).

docker run --read-only \
  --tmpfs /run \
  --tmpfs /tmp \
  -v /var/www/html/uploads:/app/uploads:rw \
  my-secure-app:latest

This forces you to be disciplined about state. State belongs in your database or persistent NVMe storage volumes, not inside the ephemeral container layer.

3. Dropping Capabilities

The Linux kernel divides root privileges into distinct units called capabilities. A web server needs to bind to port 80 (NET_BIND_SERVICE), but it definitely does not need to load kernel modules (SYS_MODULE) or change system time (SYS_TIME).

The safest approach is to drop ALL capabilities and add back only what you need. This is the whitelist approach to system calls.

docker run --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --cap-add=SETUID \
  --cap-add=SETGID \
  nginx:1.13-alpine

Pro Tip: If you are unsure which capabilities your app needs, run it briefly with --cap-drop=ALL and watch the audit logs. It will scream about what it's missing. It's better to break it in staging than leave it wide open in production.

4. Network Segmentation and the Norway Factor

Docker's default bridge network allows containers to talk to each other by IP. If your WordPress container gets hit, can it scan your MySQL container? Yes.

In 2018, we are seeing a rise in tools like Cilium (using BPF) and heavily customized iptables rules, but the foundational step is defining user-defined networks.

# Create an isolated network
docker network create --driver bridge --internal db_net

# Attach database only to internal net
docker run -d --net=db_net --name mysql_secure mysql:5.7

Furthermore, consider where your packets are flowing. Latency matters. If your users are in Oslo or Bergen, hosting in a Frankfurt datacenter adds 15-20ms of round-trip time. On a CoolVDS instance located in our Norwegian datacenter, you are hitting the NIX (Norwegian Internet Exchange) directly. Low latency isn't just about speed; it's about reducing the attack window for timing attacks and ensuring data residency compliance for strict Norwegian clients.

5. The KVM vs. LXC/OpenVZ Reality

This is where the architecture choice becomes critical. Many "cheap" VPS providers use OpenVZ or LXC. In these environments, you are sharing the host kernel directly. If a vulnerability like Meltdown allows memory reading, a bad actor on the same physical node could theoretically read your container's memory.

At CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine). When you spin up a Docker host with us, you aren't just getting a namespace; you are getting a virtualized hardware slice. Your kernel is yours. You can patch it, tune `sysctl.conf`, or harden it with GRSEC patches without asking for permission.

Implementing Seccomp Profiles

For the truly paranoid (which, in 2018, is just "prudent"), use Seccomp (Secure Computing Mode) to restrict the system calls a container can make to the kernel. Docker has a default profile, but you can tighten it.

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64"
    ],
    "syscalls": [
        {
            "name": "getcwd",
            "action": "SCMP_ACT_ALLOW",
            "args": []
        },
        {
            "name": "write",
            "action": "SCMP_ACT_ALLOW",
            "args": []
        }
    ]
}

Load this profile with --security-opt seccomp=/path/to/profile.json. It requires deep knowledge of your application's syscall footprint, but it stops 0-day kernel exploits dead in their tracks.

Final Thoughts: Compliance is Not Optional

The tech landscape in 2018 is unforgiving. We are balancing the raw performance of NVMe storage (which we provide standard on all plans) with the heavy overhead of mitigation patches for Spectre. But security is not a feature you toggle on; it's architecture.

Don't let your data float in a shared-kernel soup. Isolation is the only guarantee we have left.

Ready to lock down your stack? Deploy a hardened KVM instance on CoolVDS today and keep your data strictly under Norwegian jurisdiction.