I container hanno rivoluzionato lo sviluppo e il deployment del software moderno. Tuttavia, pensare che un container Docker offra automaticamente un isolamento a livello di macchina virtuale è un errore comune che può esporre l'host sottostante a gravi rischi di compromissione.

1. Non Eseguire Mai i Tuoi Processi Come Utente Root

Per impostazione predefinita, se non diversamente specificato nel Dockerfile, i processi all'interno del container vengono eseguiti con UID 0 (root). Se un'applicazione presenta una vulnerabilità (come una Remote Code Execution o un directory traversal su un volume montato), l'attaccante acquisisce privilegi di root.

# Best Practice nel Dockerfile:
FROM node:20-alpine
WORKDIR /app
COPY --chown=node:node package*.json ./
RUN npm ci --only=production
COPY --chown=node:node . .
USER node
CMD ["node", "server.js"]

2. Mantieni il Root Filesystem in Sola Lettura

Configurare il container con il parametro --read-only impedisce all'attaccante di scaricare ed eseguire binari malevoli o alterare file di configurazione:

docker run --read-only --tmpfs /tmp -d my-secure-app

3. Non Montare Mai il Docker Socket (docker.sock)

Montare /var/run/docker.sock all'interno di un container equivale letteralmente a consegnare i privilegi completi di root sull'intera macchina host, consentendo l'avvio immediato di container privilegiati con accesso a tutto il filesystem dell'host.

4. Applica Limiti Rigidi di Risorse (CPU & RAM)

Impedisci che un bug o un attacco Denial of Service (DoS) consumi tutta la memoria del server host definendo parametri precisi come --memory="512m" e --cpus="1.0".

5. Scansiona Continuamente le Immagini Base

Usa strumenti integrati come docker scout o scanner open-source come Trivy nella tua pipeline CI/CD per identificare CVE note prima del rilascio in produzione.

HT

HackTheory Lab

Laboratorio indipendente di sperimentazione tecnica. Spieghiamo architetture web, sicurezza offensiva e difensiva, con un occhio di riguardo al mondo open source e maker.