Stop Running Naked Containers: A Survival Guide for 2018

It is April 2018. We are exactly one month away from the GDPR enforcement deadline (May 25th), and I still see developers deploying containers with --privileged flags on production servers. If you are doing this, you aren't just risking a breach; you are inviting Datatilsynet (The Norwegian Data Protection Authority) to audit your infrastructure.

After the chaos of the Meltdown and Spectre vulnerabilities earlier this year, we learned a painful lesson: isolation is everything. Containers are fantastic for deployment velocity, but out of the box, they are essentially shared-kernel processes with a thin layer of namespace paint. If you treat Docker like a Virtual Machine, you will get burned.

I have spent the last few weeks migrating a high-traffic FinTech workload from bare metal to a containerized environment hosted in Oslo. Here is the exact security posture we adopted to keep latency low and security high, ensuring our stack survives the hostile internet of 2018.

1. The Root Problem (Literally)

By default, the process inside your Docker container runs as root. If an attacker manages a container breakout—perhaps through a dirty COW exploit or a kernel vulnerability—they are root on your host node. Game over.

You must enforce the principle of least privilege at the image level. Stop writing Dockerfiles that end without a USER instruction.

The Fix:

Create a specific user and group inside your Alpine or Debian image. Do not rely on the host's UID management.

FROM alpine:3.7

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

# Install dependencies (do this as root)
RUN apk add --no-cache curl

# Switch to the non-root user
USER appuser

# The rest runs as non-privileged
ENTRYPOINT ["./my-app"]

Pro Tip: If you are mounting volumes from the host, ensure the UID on the host matches the UID inside the container (often 1000:1000), or you will hit permission errors that tempt you to chmod 777. Never chmod 777. Fix the ownership instead.

2. Drop Capabilities Like They Are Hot

Linux capabilities break down the root user's power into distinct units. Does your Nginx web server need to load kernel modules? No. Does it need to change system time? No. Yet, by default, Docker gives it those permissions.

We use a whitelist approach. Drop everything, then add back only what is strictly necessary. This dramatically reduces the attack surface.

Configuration Example:

docker run --d --name secure-nginx \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --cap-add=CHOWN \
  --read-only \
  --tmpfs /var/cache/nginx \
  --tmpfs /var/run \
  nginx:1.13-alpine

In the example above, we also used --read-only. This mounts the container's root filesystem as read-only. If an attacker gets in, they cannot write a backdoor script or modify configurations. They are trapped in an immutable jail.

3. The Meltdown/Spectre Factor: Why Virtualization Matters

Earlier this year (January 2018), the world woke up to hardware-level vulnerabilities in Intel processors. Patches have rolled out, but they come with performance penalties.

Here is the uncomfortable truth: Containers share the host kernel. If a neighbor container triggers a kernel panic or exploits a kernel bug, your container feels it. For mission-critical data, soft isolation (cgroups/namespaces) might not be enough for strict GDPR compliance regarding data separation.

This is where the infrastructure choice becomes architectural. At CoolVDS, we don't oversell container hosting on shared kernels. We provide KVM (Kernel-based Virtual Machine) instances.

Running Docker inside a KVM instance gives you the best of both worlds: the workflow of containers and the hard security boundary of hardware virtualization.

4. Resource Limiting (The "Noisy Neighbor" Defense)

DDoS attacks are becoming cheaper. I've seen a simple fork bomb inside a container bring a poorly configured host to its knees. If you don't limit resources, one memory leak in your Java application will OOM-kill your database.

Define limits in your docker-compose.yml (version 2 or 3):

version: '3'
services:
  web:
    image: nginx:alpine
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

If you are deploying on CoolVDS, our NVMe storage backend handles high I/O remarkably well, but you should still use --device-write-bps if you have a log-heavy application to prevent it from saturating your disk throughput.

5. Secrets Management

I still see developers passing database passwords via environment variables: -e DB_PASS=supersecret. Anyone who runs docker inspect on your container can see that password. It is also often logged in shell history.

Stop it. Docker Swarm (available since 1.12) has native secrets management. If you aren't using Swarm or Kubernetes, mount the secret as a file from a protected volume on the host, which is only readable by the root user of the host.

Conclusion: Security is a Process, Not a Product

The regulatory landscape in Europe is shifting. With GDPR arriving in May, data sovereignty and security are legal requirements, not just technical preferences. Hosting your data in Norway (outside the EU but EEA-compliant) on CoolVDS hardware ensures you meet strict privacy standards while benefiting from low latency to Northern Europe.

Don't wait for a breach to tighten your security. Start by locking down your base images and moving to a KVM-based infrastructure.

Ready to secure your stack? Deploy a hardened KVM instance on CoolVDS today and get true kernel isolation for your Docker environment.