Stop Trusting Default Configurations: A Survival Guide for 2024

I still see it in production logs every week. A startup in Oslo or a fintech in Bergen deploys a critical microservice, and the Dockerfile ends with USER root. Implicitly, of course. Because they didn't specify otherwise. They assume the container boundary is a magic shield. It isn't. It is a shared kernel namespace, and if a vulnerability like Leaky Vessels (CVE-2024-21626) taught us anything earlier this year, it's that container escapes are not theoretical physics—they are scripted exploits available on GitHub.

As a sysadmin who has spent the last decade fighting fires in the Nordic hosting market, I can tell you that compliance isn't just about satisfying Datatilsynet or checking a GDPR box. It is about ensuring that one compromised Node.js app doesn't hand over the keys to your entire infrastructure. If you are running containers on cheap, oversold shared hosting, you are already losing.

1. The Privilege Problem: Drop Capabilities

By default, Docker grants a container a broad set of Linux capabilities. Most applications do not need them. Does your Nginx proxy need to modify system time? Does your Python worker need to craft raw packets? No. Yet, standard configurations leave CAP_NET_RAW and CAP_SYS_CHROOT wide open.

We adopt a "deny-all" strategy. You drop everything and add back only what is strictly necessary. This significantly reduces the attack surface if an attacker gains shell access inside the container.

# The wrong way
docker run -d my-app

# The right way: Drop all, add specific
docker run -d --cap-drop=ALL --cap-add=NET_BIND_SERVICE --read-only my-app

In a Kubernetes context, this translates to the securityContext. If you are deploying on a managed cluster or your own Kubeadm setup on CoolVDS, this should be your baseline for every single pod.

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: app
    image: my-secure-image:1.4.2
    securityContext:
      allowPrivilegeEscalation: false
      runAsNonRoot: true
      runAsUser: 10001
      capabilities:
        drop:
        - ALL
        add:
        - NET_BIND_SERVICE
      readOnlyRootFilesystem: true

2. The Infrastructure Layer: KVM vs. Containers-as-a-Service

Here is the uncomfortable truth many hosting providers hide. If you buy a "container VPS" that is actually just an OpenVZ or LXC container itself, you are sharing the kernel with every other customer on that physical node. If Neighbor A triggers a kernel panic or exploits a kernel vulnerability, Customer B (you) goes down or gets exposed.

This is why specific architecture matters. At CoolVDS, we exclusively use KVM (Kernel-based Virtual Machine) for our NVMe instances. This provides hardware-level virtualization. Your kernel is yours. The isolation is rigid. When handling sensitive Norwegian citizen data, relying on soft isolation mechanisms is negligence.

Pro Tip: Always check uname -r inside your VPS. If it matches the host kernel of a budget provider exactly and you can't install kernel modules, you aren't on a real VPS. You're in a glorified chroot. Move your workload.

3. Supply Chain Security: Scanning at the Gate

In October 2024, deploying an image without scanning it is professional suicide. Supply chain attacks have shifted from targeting the running application to targeting the base image. You might write secure code, but if your base alpine:3.19 image has a critical vulnerability, you are exposed.

We integrate Trivy into the CI/CD pipeline. It’s fast, open-source, and has a low false-positive rate compared to older tools.

# rapid scan command
trivy image --severity HIGH,CRITICAL --ignore-unfixed my-app:latest

Don't just scan for OS packages. Scan your language dependencies. A malicious NPM package or PyPI dependency is a common vector. Trivy handles both.

4. Network Policies: The Forgotten Firewall

By default, in Kubernetes and Docker bridges, all traffic is allowed. Front-end pods can talk to the database directly? That’s a flat network topology, and it’s dangerous. If an attacker compromises the web server, they shouldn't have a direct TCP line to your primary Postgres instance.

Implement NetworkPolicies to restrict traffic. In Norway, where data sovereignty is paramount, ensuring traffic doesn't accidentally route through non-compliant proxies is vital.

Below is a restrictive policy that denies all ingress traffic by default, forcing you to whitelist specific paths.

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

5. Runtime Defense with Falco

Static analysis is great, but what happens during the attack? If someone spawns a shell in a container that should only be running a Java process, you need to know immediately. Falco is the standard for this behavioral monitoring.

In high-compliance environments (like handling health data in Norway), we run Falco agents on our CoolVDS nodes to detect anomalies. A simple rule to detect a shell spawning in a container looks like this:

- rule: Terminal shell in container
  desc: A shell was used as the entrypoint or execve
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container_entrypoint
  output: "Shell spawned in a container (user=%user.name container=%container.name)"
  priority: WARNING

6. The Latency & Legal Argument

Why host these hardened containers in Norway? Two reasons: Latency and Law.

If your users are in Oslo, routing traffic to a data center in Frankfurt adds unnecessary milliseconds. On CoolVDS, routing through NIX (Norwegian Internet Exchange) ensures your API response times are minimal. We are talking sub-20ms round trips for local users. Performance is a security feature; slow services encourage users to bypass security controls.

Furthermore, post-Schrems II, the legal landscape regarding data transfers to US-owned clouds is... complex. Hosting on local infrastructure like CoolVDS simplifies GDPR compliance significantly. You know exactly where the physical drive sits.

Summary Checklist for Deployment

Security is not a product you buy; it is a process you adhere to. But having the right foundation helps. Don't build your castle on a swamp. If you need a robust, low-latency, KVM-based environment to run your secure workloads, we have the hardware ready.

Stop fighting with noisy neighbors and slow I/O. Spin up a secure, NVMe-powered instance on CoolVDS today and lock down your infrastructure properly.