The "Isolation" Lie We Tell Ourselves
Let's rip the band-aid off immediately: Containers are not Virtual Machines. They are just processes with a fancy raincoat (namespaces) and a leash (cgroups). I've audited clusters for fintechs in Oslo where the CTO believed a Docker container was a hard security boundary. It wasn't. A kernel exploit allowed a compromised web scraper to break out, traverse the host, and read memory from adjacent pods. If you are running sensitive workloads on shared, oversold hosting without hardware-level virtualization, you are playing Russian Roulette with your data.
In 2025, with the Norwegian Data Protection Authority (Datatilsynet) handing out fines like parking tickets, "good enough" security isn't enough. We need to talk about immutable infrastructure, kernel capability dropping, and why the underlying hardware matters more than your Kubernetes version.
1. The Root Problem (Literally)
By default, the root user inside a container is the same root user on the host kernel. If an attacker executes code execution inside your Node.js app running as UID 0, they are one syscall vulnerability away from owning your entire server.
We fix this at the build stage. Do not ship build tools to production. Do not run as root. Here is the reference implementation for a secured multi-stage build that we use for internal CoolVDS microservices:
# Stage 1: Build
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Stage 2: Runtime (Distroless or Minimal)
FROM node:22-alpine
# Create a non-root user specifically for this service
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
# Copy only necessary artifacts
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
# Lock it down
USER appuser
# Prevention is better than cure: Read-only root filesystem
CMD ["node", "dist/server.js"]
Pro Tip: Never rely on the default namespace isolation. Always verify your user limits. In Norway, where industrial espionage in the energy sector is a real threat vector, we recommend auditing your `uid_map` explicitly.
2. Runtime Defense: Starving the Attacker
Once an attacker gets a shell (if you were foolish enough to leave one in the image), their next step is to write a payload to disk or open a reverse shell. You can block 90% of these vectors by making the container filesystem read-only.
If your application needs to write logs or temp files, mount a `tmpfs` volume. Do not let the container write to its own root.
docker run --read-only --tmpfs /tmp --tmpfs /run my-secure-app
For Kubernetes deployments, we enforce this via the Pod Security Standards (PSS). The old PodSecurityPolicies are dead and buried. If you are still using them in 2025, you are technically obsolete. Use the `securityContext` in your deployment manifests:
apiVersion: apps/v1
kind: Deployment
metadata:
name: secure-payment-gateway
spec:
template:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 10001
fsGroup: 10001
seccompProfile:
type: RuntimeDefault
containers:
- name: payment-api
image: registry.coolvds.com/payment-api:v2.4
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
3. Network Segmentation (The GDPR Firewall)
Under GDPR and local Norwegian interpretations, data minimization applies to network traffic too. Why can your Frontend Pod talk to your Database Pod? It should talk to the API Pod, which talks to the Database. Flat networks are a security failure.
We use Cilium or Calico CNI to enforce strict NetworkPolicies. A "Default Deny" policy is mandatory for any environment I architect.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
# No rules means nothing gets in or out by default.
# You must explicitly whitelist traffic.
4. Supply Chain: Trust Nothing
You are likely pulling images from Docker Hub. Stop it. You are pulling vulnerabilities that were patched three months ago. Use a private registry and scan every single layer before it hits your cluster. Tools like Trivy are non-negotiable in the CI/CD pipeline.
trivy image --severity HIGH,CRITICAL --exit-code 1 my-app:latest
If this command fails, the pipeline stops. No exceptions. Not even for the CEO's urgent demo.
5. The Infrastructure Reality Check
You can have the most hardened Kubernetes manifest in existence, but if your underlying VPS provider uses cheap container-based virtualization (like OpenVZ or LXC) without strict tuning, you are sharing the kernel with every other customer on that node. A kernel panic triggered by a neighbor brings you down. A noisy neighbor steals your I/O.
This is why we built CoolVDS on KVM (Kernel-based Virtual Machine). We provide hardware-level virtualization. Your kernel is your kernel. This is critical for VPS Norway deployments where low latency is expected but stability is demanded.
Kernel Parameter Tuning
On a dedicated KVM slice from CoolVDS, you have the authority to modify sysctl parameters to thwart network attacks, something often blocked on shared container platforms.
sysctl -w net.ipv4.conf.all.accept_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0
6. Runtime Detection with Falco
Static analysis is great; runtime detection is better. Falco acts as a security camera for syscalls. If a container suddenly tries to read `/etc/shadow`, Falco screams.
- rule: Terminal shell in container
desc: A shell was used as the entrypoint for a started container
condition: >
spawned_process and container
and shell_procs and proc.tty != 0
and container_entrypoint
output: >
Shell executed in container (user=%user.name %container.info)
priority: WARNING
When this alert fires, we don't just log it. We trigger a webhook to cordon the node and kill the pod immediately.
Conclusion
Security is not a product; it is a process of reducing risk. By stripping capabilities, locking down the network, and scanning images, you make yourself a hard target. But remember: software hardening cannot fix hardware sharing weaknesses.
For workloads that demand compliance and genuine isolation, stop sharing kernels with strangers. Deploy your hardened containers on a CoolVDS KVM instance today. We offer native NVMe storage and direct peering at NIX in Oslo, ensuring your encrypted traffic stays within Norwegian borders.
Secure your infrastructure now. Spin up a CoolVDS instance in 55 seconds.