Stop Trusting Your Containers: A Survival Guide for 2023
I recently watched a 'secure' Kubernetes cluster get compromised in less than four minutes. The attacker didn't use a zero-day. They didn't crack a complex password. They simply exploited a misconfigured container running as root with unrestricted egress access. Once inside, they pivoted, pulled a crypto-miner script, and melted the CPU cores. If this had been a production database for a Norwegian fintech firm, the GDPR fines from Datatilsynet would have buried them.
Containers are not sandboxes. They are processes with a fancy view of the operating system. If you treat Docker or Kubernetes as a magic security shield, you will get burned. Here is how we lock down infrastructure effectively, specifically tailored for the threat landscape we see in Europe right now.
1. The Root Problem (Literally)
By default, processes inside a container run as root. If that process escapes—via a kernel vulnerability—it is root on your host. Game over. You must enforce non-root execution. In 2023, there is zero excuse for running standard microservices as UID 0.
The Fix: Create a specific user in your Dockerfile.
FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
WORKDIR /home/appuser
COPY . .
CMD ["./app"]
Furthermore, within your Kubernetes manifests, you must enforce this using the securityContext. Since Kubernetes 1.25, Pod Security Policies (PSP) are dead. You should be using Pod Security Standards (PSS) or an admission controller like Kyverno or OPA Gatekeeper.
Here is a strictly confined Pod specification:
apiVersion: v1
kind: Pod
metadata:
name: secure-app
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: main
image: my-app:1.2.3
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
Pro Tip: DroppingALLcapabilities is aggressive. You might need to add back specific ones likeNET_BIND_SERVICEif you are binding to low ports, though standard practice suggests binding to ports > 1024 to avoid this requirement entirely.
2. Supply Chain: Your Image is Probably Dirty
In August 2023, supply chain attacks are the norm. If you pull node:latest, you are gambling. You need to scan images before they ever touch your production environment. We use Trivy in our CI/CD pipelines. It’s fast, open-source, and integrates with everything.
Running a scan manually:
trivy image --severity HIGH,CRITICAL python:3.9-slim
If you see Critical CVEs with fixes available, the build fails. Period. Do not deploy known vulnerabilities hoping nobody finds them. Scanners are constantly crawling the internet; they will find them.
3. Runtime Defense with Falco
Static analysis isn't enough. You need to know what happens when the container is running. If a web server process suddenly spawns a shell or tries to modify /etc/shadow, you need an alert immediately. Falco is the standard for this.
A basic Falco rule to detect a shell spawning in a container:
- rule: Terminal shell in container
desc: A shell was used as the entrypoint/exec point into a container with an attached terminal.
condition: >
spawned_process and container
and shell_procs and proc.tty != 0
and container_entrypoint
output: >
A shell was spawned in a container with an attached terminal (user=%user.name %container.info
shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline terminal=%proc.tty container_id=%container.id image=%container.image.repository)
priority: NOTICE
4. The Infrastructure Layer: Isolation Matters
This is where hardware and virtualization choices become critical. Containers share the host kernel. If you run your containers on a cheap, oversold OpenVZ VPS, you are sharing a kernel with potentially hundreds of other noisy, possibly malicious neighbors. Kernel exploits (like Dirty Pipe from last year) can affect everyone on that node.
This is why serious DevOps teams prefer KVM-based virtualization, which is the standard at CoolVDS. KVM provides a hardware-assisted virtualization layer. Even if a container escapes to the VM host, it is still trapped inside your dedicated environment, not on the bare metal shared by other customers.
Comparison: Hosting Architectures
| Feature | Shared Container Platform | CoolVDS (KVM NVMe) |
|---|---|---|
| Kernel Isolation | Weak (Shared) | Strong (Dedicated) |
| I/O Performance | Variable/Throttled | Dedicated NVMe |
| Data Sovereignty | Often opaque | Strict (Norway/EU) |
5. Network Policies: Zero Trust Inside the Cluster
By default, all pods in a Kubernetes cluster can talk to all other pods. Your frontend does not need to talk to your Redis cache directly; only the backend API does. Use NetworkPolicies to restrict traffic.
Here is a policy that denies all ingress traffic by default (whitelist model):
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
You then explicitly allow only necessary connections. This limits the blast radius if a single service is breached.
6. The Norwegian Context: GDPR & Latency
We operate in a post-Schrems II world. The recent adequacy decision (July 2023) regarding the EU-US Data Privacy Framework eases tension slightly, but uncertainty remains. Datatilsynet advises caution. Storing customer data on US-controlled clouds is still a legal headache for many Norwegian entities.
Hosting locally solves two problems:
- Compliance: Data stays on servers physically located in Norway/Europe, governed by our laws.
- Performance: If your customers are in Oslo or Bergen, routing traffic to Frankfurt or Virginia adds unnecessary milliseconds. With CoolVDS, you are hitting the Norwegian Internet Exchange (NIX) almost instantly. Low latency isn't just a luxury; it's a ranking factor.
Conclusion
Security is not a product; it is a process of reducing risk. By hardening your container runtimes, scanning your supply chain, and running on isolated KVM infrastructure like CoolVDS, you make yourself a hard target. Hackers are opportunistic. They look for open doors, not bank vaults.
Don't wait for a breach to audit your stack. Deploy a hardened test cluster on a CoolVDS NVMe instance today and see the difference raw performance and true isolation make.