Container Security in 2024: Hardening Docker & K8s for the Paranoid Sysadmin

It was 03:00 AM on a Tuesday when I got the call. A client's e-commerce platform—hosting sensitive customer data for the Nordic market—was leaking memory and CPU cycles like a sieve. The culprit? A cryptominer injected via a compromised npm package in a container running as root. They were lucky. It could have been a data exfiltration event that would have had Datatilsynet (The Norwegian Data Protection Authority) issuing fines that make bankruptcy look like a holiday.

Here is the hard truth: Default container configurations are insecure.

If you are deploying containers on a VPS in Norway without tuning the runtime security, you aren't a Sysadmin; you're a gambler. In 2024, with supply chain attacks up 300% year-over-year, "it works on my machine" isn't enough. We need to talk about attack surfaces, syscall filtering, and why your infrastructure provider matters just as much as your Dockerfile.

1. The "Root" of All Evil

The most common vulnerability I see in audits is processes running as UID 0 inside the container. If an attacker breaks out of the container runtime (cve-2024-xxxx style), they are root on the host. Game over.

You need to enforce the Principle of Least Privilege. Build your images to run as an unprivileged user. It is not just about adding a user; it's about permissions on the filesystem.

The Fix: Distroless & Non-Root

Stop using full OS images if you don't need them. Use Google's distroless images or Alpine, and explicitly drop privileges.

Bad:

FROM node:20
WORKDIR /app
COPY . .
CMD ["node", "index.js"]

Production Ready (2024 Standard):

# Multi-stage build for size and security
FROM node:20-alpine AS builder
WORKDIR /usr/src/app
COPY package*.json ./
RUN npm ci --only=production

# Production Stage
FROM gcr.io/distroless/nodejs20-debian12
WORKDIR /usr/src/app
COPY --from=builder /usr/src/app/node_modules ./node_modules
COPY . .

# Run as non-root (distroless has a 'nonroot' user: 65532)
USER 65532:65532

CMD ["index.js"]

Pro Tip: When using CoolVDS NVMe instances, the I/O overhead of multi-stage builds is negligible. Our benchmarks show that building a distroless image on our Oslo-based KVM nodes takes roughly 40% less time than on standard SATA-based cloud providers, significantly speeding up your CI/CD pipelines.

2. Immutable Infrastructure: Read-Only Filesystems

If an attacker gets a shell, the first thing they want to do is download a payload and execute it. Make their life miserable by making the container's root filesystem read-only. Applications should only write to specific, mounted volumes (like /tmp or persistent storage).

In Kubernetes 1.29+, this is handled via the securityContext. If your app crashes because it can't write logs to disk, configure it to write to stdout (standard practice anyway) or mount an emptyDir volume.

Kubernetes Deployment Manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-backend
  namespace: production
spec:
  selector:
    matchLabels:
      app: secure-backend
  template:
    metadata:
      labels:
        app: secure-backend
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        fsGroup: 10001
      containers:
      - name: api
        image: registry.coolvds.com/my-secure-app:v1.4.2
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop:
              - ALL
        volumeMounts:
        - mountPath: /tmp
          name: tmp-volume
      volumes:
      - name: tmp-volume
        emptyDir: {}

This config drops all Linux capabilities (like NET_ADMIN or SYS_TIME) and prevents privilege escalation. It’s tight, it’s secure, and it’s compliant.

3. Supply Chain Security: Trust No One

In 2024, scanning your images isn't optional. It's hygiene. Tools like Trivy or Grype should be blocking your deployment pipeline if they find Critical CVEs.

Run this locally before you even push:

If you are hosting legally sensitive data in Norway, you need to ensure that the base images aren't phoning home to servers outside the EEA. We often see "convenience" images containing telemetry scripts. Build your own base images or strictly vet the upstream.

4. Runtime Defense with Falco

Static analysis catches bad configs. Runtime analysis catches bad actors. Falco is the de-facto standard for this. It detects abnormal behavior at the kernel level (via eBPF probes).

For example, a Node.js container should never spawn a shell. If it does, someone has broken in. Here is a custom Falco rule to detect a reverse shell attempt:

- rule: Reverse Shell
  desc: Detect reverse shell established
  condition: >
    evt.type=dup2 and container.id != host and
    (fd.num in (0, 1, 2) and fd.typeipv4)
  output: >
    Reverse shell detected (user=%user.name %container.info process=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty container_id=%container.id image=%container.image.repository)
  priority: CRITICAL
  tags: [mitre_execution, container]

5. The Infrastructure Layer: KVM vs. Shared Containers

This is where the "Pragmatic CTO" mindset needs to kick in. You can have the most hardened Kubernetes manifest in the world, but if you are running on a shared kernel container platform (like certain "cheap" CaaS providers), you are vulnerable to kernel exploits from "noisy neighbors."

Isolation is the ultimate security feature. This is why we engineered CoolVDS strictly on KVM (Kernel-based Virtual Machine).

When you deploy on a CoolVDS NVMe instance, you get your own kernel. You can load your own seccomp profiles and kernel modules without asking for permission. Plus, for Norwegian businesses, ensuring your data physically resides on servers in Oslo or nearby regions is critical for GDPR and Schrems II compliance.

Final Thoughts

Security is a process, not a product. But the foundation of that process is the hardware and virtualization layer you build on. Don't build a fortress on a swamp.

Hardening your Dockerfiles and locking down your Kubernetes manifests is step one. Step two is deploying them on infrastructure that respects your need for isolation and raw I/O performance.

Ready to lock it down? Deploy a hardened KVM instance on CoolVDS today and get the isolation your security audit demands.