Container Security 2025: Hardening K8s & Docker for the Norwegian Cloud

I still wake up in a cold sweat thinking about the "Log4Shell" winter. If you were managing infrastructure back then, you remember the chaos. But here we are in late 2025, and while the CVEs have changed, the fundamental problem hasn't: developers want velocity, and security teams want to lock everything down until it barely functions.

In the Nordic hosting market, the stakes are higher. We aren't just dealing with script kiddies; we are dealing with strict Datatilsynet audits and the absolute requirement for data sovereignty within the EEA. If your container breaks out and leaks PII, you aren't just fixing a bug; you are hiring lawyers.

This isn't a high-level policy document. This is a technical breakdown of how to harden your container stack, specifically tailored for infrastructure running in Oslo-based data centers like CoolVDS, where we treat latency and isolation as religion.

1. The "Latest" Tag is a Lie

If your CI/CD pipeline pulls node:latest or ubuntu:latest, you are deploying a time bomb. By the time 2025 rolled around, supply chain attacks targeting public registries became the norm. You need deterministic builds. If you can't verify the SHA256 digest, don't run it.

Stop writing Dockerfiles like it's 2018. Use multi-stage builds and strip the runtime image to the bone. Here is how we build secure Go microservices for our internal metrics collectors:

# Build Stage
FROM golang:1.24-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o server main.go

# Production Stage
# Using a specific digest for immutability (Distroless)
FROM gcr.io/distroless/static-debian12@sha256:4433370928230009230...
COPY --from=builder /app/server /server
USER nonroot:nonroot
ENTRYPOINT ["/server"]

Pro Tip: Always use distroless images or alpine where possible. A shell-less container prevents an attacker from easily running commands even if they gain RCE. If /bin/sh doesn't exist, their reverse shell script fails.

2. Kernel Isolation & The CoolVDS Advantage

Containers are just processes. They share the host kernel. If you are running on cheap, oversold VPS providers that use LXC or OpenVZ, a kernel panic in a neighbor's container can bring your database down. Worse, a container escape vulnerability (like the Leaky Vessels exploits of 2024) allows an attacker to jump from the container to the host.

This is where infrastructure choice matters. At CoolVDS, we enforce strict KVM (Kernel-based Virtual Machine) virtualization. Your VPS has its own dedicated kernel. If you mess up your `sysctl` settings, you only crash your own instance, not the whole rack.

3. Runtime Security with eBPF

Static scanning with Trivy is great, but it only catches known vulnerabilities. It won't stop a zero-day. In 2025, eBPF (Extended Berkeley Packet Filter) is the standard for runtime security. Tools like Falco allow us to monitor syscalls in real-time with negligible overhead.

Here is a Falco rule we use to detect if a container tries to modify a binary in a registered directory (classic malware behavior):

- rule: Write below binary dir
  desc: an attempt to write to any file below a set of binary directories
  condition: >
    evt.type in (open, openat, openat2, creat) and 
    fd.writable=true and 
    (fd.name startswith /bin or 
     fd.name startswith /usr/bin or 
     fd.name startswith /sbin)
  output: "File below a known binary directory opened for writing (user=%user.name command=%proc.cmdline file=%fd.name)"
  priority: CRITICAL

When you run high-performance NVMe storage, you don't want security agents eating up your I/O. eBPF runs in the kernel space, making it blazing fast.

4. Locking Down Kubernetes Contexts

If you are deploying to K8s, the securityContext is mandatory. Do not accept defaults. We enforce a policy that prevents root escalation. If an application requires root, it requires a re-architecture meeting.

Here is the standard securityContext block you should inject into every Deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      securityContext:
        runAsUser: 1000
        runAsGroup: 3000
        fsGroup: 2000
      containers:
      - name: app
        image: my-registry/app:v1.2.0
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          capabilities:
            drop:
              - ALL

5. The Network is the Firewall

In a flat network, a compromised frontend can scan your database directly. Zero Trust isn't a buzzword; it's a NetworkPolicy. By default, Kubernetes allows all traffic. You need to explicitly deny everything and only whitelist what is necessary.

This policy isolates a namespace completely, forcing you to open ports manually:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

6. Local Compliance & Latency

Security is also about availability and legality. Hosting your containers on a cloud provider with data centers in the US or even Frankfurt might introduce latency that Norwegian users feel. More importantly, Schrems II regulations make transferring personal data outside the EEA risky.

CoolVDS operates directly out of Oslo. We peer directly at NIX (Norwegian Internet Exchange). This means your packets often don't even leave the country, reducing the attack surface for Man-in-the-Middle attacks and keeping the Datatilsynet happy.

Comparison: Shared Container Hosting vs. CoolVDS KVM

Conclusion

Container security is a game of layers. You strip the image, you lock the runtime with eBPF, you restrict the orchestrator with SecurityContexts, and finally, you run it on hardware that respects isolation. Don't let a misconfigured YAML file be the reason you're patching servers on a Friday night.

If you need a sandbox that mimics this hardened production environment, spin up a CoolVDS instance. It takes 55 seconds, gives you full root access, and sits on the fastest NVMe storage in Norway.