The "Sandbox" Lie: Container Isolation is a Myth

Let's clear the air immediately: a container is not a sandbox. It is a process with a fancy seatbelt. If you are deploying containers in production assuming they offer the same isolation as a Virtual Machine, you are architecting a disaster. I have spent the last week cleaning up a client's cluster where a single compromised container led to a host-level privilege escalation. Why? Because in December 2020, far too many of you are still writing Dockerfile configurations like it is 2015.

With the recent tremors in the supply chain—yes, I am looking at the SolarWinds fallout—and the absolute chaos caused by the CentOS 8 EOL announcement last week, stability and security are the only metrics that matter. If you are running mission-critical workloads in Norway, you have the added pressure of the Datatilsynet breathing down your neck regarding Schrems II. You cannot afford a leaky abstraction.

1. Stop. Running. As. Root.

The default user in a Docker container is root (UID 0). If an attacker manages to break out of the container runtime—via a vulnerability like CVE-2019-5736 or similar runC exploits—they are root on your host node. Game over.

The fix is trivial, yet rarely implemented. Create a dedicated user in your image. Do not rely on the runtime to do it for you.

FROM alpine:3.12

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

# Tell Docker to use this user
USER appuser

WORKDIR /home/appuser
COPY --chown=appuser:appgroup . .

ENTRYPOINT ["./my-binary"]

By strictly defining the USER directive, you mitigate a massive class of kernel-level exploits. If your application tries to bind to port 80 or 443, it will fail because non-root users cannot bind to ports under 1024. Good. Use a reverse proxy like Nginx or Traefik to handle ingress, or configure sysctl capabilities if you absolutely must bind low ports (though you shouldn't).

2. Drop Linux Capabilities

Even if you run as a non-root user, the Linux kernel grants default capabilities to the container process. Most web apps do not need NET_RAW (used for ping) or MKNOD. The principle of least privilege applies to kernel calls too.

If you are using Docker directly:

If you are orchestrating with Kubernetes (and you should be upgrading to 1.19 or the fresh 1.20 release to get the latest security contexts), your Deployment YAML needs to be explicit. Do not rely on defaults.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
      containers:
      - name: app
        image: my-registry/app:v2
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
            add:
            - NET_BIND_SERVICE

3. The Immutable Filesystem

Persistence is the enemy of security in stateless microservices. If an attacker gains shell access, the first thing they want to do is download a payload or modify a configuration file. Make their life miserable by mounting the root filesystem as read-only.

This forces you to be disciplined about where you write data. Logs go to STDOUT/STDERR. Temporary files go to /tmp (which should be a tmpfs mount). Data goes to persistent volumes or external databases.

Pro Tip: In your Docker compose or runtime flags, use --read-only. If your app crashes because it can't write to a config folder, fix the app, don't relax the security.

4. Supply Chain Security and Image Scanning

You are pulling images from Docker Hub. Do you know what is in them? node:latest changes every time you build. We are seeing a massive uptick in typosquatting attacks on public registries.

Before any image hits your production cluster, it must be scanned. In late 2020, Trivy by Aquasecurity has emerged as the sharpest tool for this. It is faster than Clair and easier to integrate into CI/CD pipelines. It scans OS packages and language dependencies (Gemfile, package-lock.json, etc.).

# Install Trivy (v0.15.0)
apt-get install trivy

# Scan your image before pushing
trivy image --severity HIGH,CRITICAL my-app:latest

If this command returns a non-zero exit code, your build pipeline should fail. No exceptions.

5. The Infrastructure Layer: Why CoolVDS Matters

Here is the hard truth about container security: Containers share the host kernel. If there is a kernel panic or a deep-level exploit, every container on that host is at risk. This is the "noisy neighbor" problem on steroids.

This is why high-security environments in the Nordics are moving away from purely shared container hosting (CaaS) and back to robust Virtual Private Servers (VPS) as the container host. You need a hypervisor between you and the metal.

At CoolVDS, we don't oversell our cores. We use KVM (Kernel-based Virtual Machine) virtualization. Unlike OpenVZ or LXC, KVM provides hardware-level virtualization. Your kernel is your kernel. If a neighbor on the physical node gets compromised, they are trapped in their own virtualized hardware, unable to touch your memory space.

The Schrems II Factor

Since the CJEU invalidated the Privacy Shield in July, relying on US-owned cloud providers for hosting Norwegian user data is a legal minefield. The Datatilsynet has been clear: you are responsible for the transfer mechanisms. Hosting on CoolVDS, where data resides physically in Oslo on infrastructure owned by a European entity, simplifies your compliance posture significantly. We are not subject to the US CLOUD Act.

Conclusion: Defaults are for Amateurs

Security is not a product; it is a configuration state. By the time you read about a vulnerability on Hacker News, automated bots have been scanning for it for 48 hours. Hardening your Docker images and Kubernetes manifests is the baseline.

But software hardening implies your infrastructure can hold the weight. Do not put bulletproof vests on a skeleton. Ensure your base layer is solid.

If you need low-latency access to the Norwegian market and infrastructure that respects your data sovereignty, stop guessing with shared hosting.

Don't let a kernel panic take down your business. Deploy a KVM-backed, NVMe-powered instance on CoolVDS in 55 seconds.