Container Isolation Is A Lie: Hardening Strategies for 2025

Let’s be brutally honest. If you are running containers with default settings in production, you aren't deploying infrastructure; you are deploying a playground for attackers. I’ve spent the last decade cleaning up after "move fast and break things" teams who realized too late that --privileged is not a debugging flag—it’s a resignation letter.

In the Nordic market, where compliance with Datatilsynet and strict GDPR adherence is not optional, relying on the flimsy isolation of a default namespace is negligence. We recently audited a fintech setup in Oslo where a single compromised pod had read access to the host’s /proc file system simply because nobody bothered to drop capabilities. Total compromise took less than twelve minutes.

Real security isn't about buying a fancy dashboard. It's about reducing the attack surface until there is nowhere left to hide. Here is how we harden environments at the architectural level, and why the underlying hardware abstraction layer—specifically the KVM virtualization we mandate at CoolVDS—is your first line of defense.

1. The Root Cause is Literally Root

It is 2025. There is zero excuse for running processes as root inside a container. When a process runs as UID 0 inside a container, it retains significant privileges on the host kernel unless you have mapped user namespaces perfectly (which you probably haven't).

If an attacker breaks out of the application, you want them to land in the shell as a nobody, not as the king of the castle. You must enforce a non-root user at the image build stage.

The "Golden Image" Dockerfile

Stop using full OS base images. Use distroless or Alpine, and strip it down. Here is a battle-tested multi-stage build pattern we use for high-security Go applications:

# Build Stage
FROM golang:1.24-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -ldflags="-w -s" -o server main.go

# Final Stage
FROM gcr.io/distroless/static:nonroot
WORKDIR /
COPY --from=builder /app/server .

# Enforce non-root user (ID 65532 is standard for distroless)
USER 65532:65532

ENTRYPOINT ["/server"]

By using distroless, there is no shell. Even if they get Remote Code Execution (RCE), they cannot run /bin/bash because it simply doesn't exist.

2. Kernel Capabilities: Drop 'Em All

The Linux kernel divides the privileges traditionally associated with superuser into distinct units, known as capabilities. By default, Docker grants significant capabilities like CHOWN, NET_RAW, and SETUID. Most web apps need none of these.

Start with a deny-all approach. Drop everything, then add back only what is strictly necessary. This prevents a compromised process from manipulating network stacks or changing file ownership.

Small Config Example:

If you are orchestrating via Kubernetes, this goes into your SecurityContext. This is non-negotiable for any workload running on our Oslo nodes.

3. Immutable Infrastructure is Not Just a Buzzword

Drift is the enemy of security. If a container is running, its filesystem should be read-only. This prevents attackers from downloading malware, modifying configurations, or establishing persistence. If your application needs to write data, mount a tmpfs or a persistent volume.

Locking it down:

Pro Tip: When using CoolVDS NVMe storage, mounting external volumes doesn't introduce the I/O latency penalty you see with budget providers. Our direct-path storage ensures that even offloaded logs write at near-native speeds.

4. Seccomp: The System Call Firewall

If capabilities limit what a user can do, Secure Computing Mode (seccomp) limits what the kernel will listen to. A standard Linux kernel exposes 300+ system calls. Your Node.js app probably uses about 40. The other 260 are just open doors for kernel exploitation.

We see massive CPU overhead reduction and security gains by applying strict seccomp profiles. Below is a snippet of a profile that blocks dangerous calls often used in privilege escalation exploits:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64"
    ],
    "syscalls": [
        {
            "names": [
                "accept4",
                "bind",
                "listen",
                "connect",
                "read",
                "write",
                "exit_group"
            ],
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": [
                "clone",
                "mount",
                "pivot_root",
                "swapon",
                "uselib"
            ],
            "action": "SCMP_ACT_KILL"
        }
    ]
}

Applying this profile effectively neutralizes a wide class of kernel exploits before they even execute.

5. The Isolation Layer: Why Your Host Matters

Here is the uncomfortable truth: Containers share the host kernel. If a vulnerability exists in the kernel (like the Dirty Pipe exploit from a few years back), a container can crash the host or escape to the host OS.

This is where the choice of VPS provider becomes critical. Many budget hosts use container-based virtualization (like OpenVZ or LXC) to provision your "server". This means you are sharing a kernel not just with your own containers, but with other customers. That is a security failure by design.

At CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine). Each VPS gets its own dedicated kernel. Even if your container runtime is compromised, the attacker is trapped inside your VM, unable to touch the hypervisor or other tenants. For high-compliance sectors in Norway, KVM is the minimum standard.

6. Network Segmentation

Flat networks are relics of the past. In a microservices architecture, the database should never talk to the frontend load balancer directly. It should only accept connections from the backend service.

If you are using Kubernetes, NetworkPolicies are mandatory. By default, all pods can talk to all pods. We need to shut that down.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
--- 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend-api
    ports:
    - protocol: TCP
      port: 5432

7. Supply Chain: Inspect Before You Deploy

You wouldn't eat food found on the sidewalk. Don't pull images from Docker Hub blindly. Supply chain attacks have surged in 2024 and 2025, with malicious packages injected into upstream dependencies.

Scan it:

Verify signatures:

Automate this in your CI/CD pipeline. If the scan fails, the build breaks. No exceptions.

Conclusion: Performance Meets Paranoia

Hardening containers introduces complexity, but it is the cost of doing business in a hostile digital environment. However, security layers often come with performance overheads—seccomp filters and encrypted overlay networks consume CPU cycles.

This is why the underlying metal matters. You cannot afford "noisy neighbors" stealing CPU cycles when your encryption routines need them. CoolVDS offers high-frequency compute instances in Oslo that absorb this overhead without flinching. We provide the raw power you need to run secure, compliant, and isolated workloads without sacrificing latency.

Don't wait for a breach to take architecture seriously. Audit your Dockerfiles today, drop those capabilities, and move your critical workloads to a KVM-backed infrastructure that respects your data sovereignty.