Blog
Una checklist pratica di sicurezza per l'isolamento Docker in hosting multi-tenant
Proteggi il tuo hosting Docker multi-tenant con questa checklist pratica che copre utenti non root, capabilities, seccomp, namespace utente, limiti delle risorse e filesystem di sola lettura.
Riepilogo
L'hosting Docker multi-tenant richiede un forte isolamento per prevenire fughe dai container. Questo articolo fornisce una checklist pratica di sicurezza che copre sei aree chiave: eseguire come non root, rimuovere capabilities, applicare profili seccomp, abilitare il re-mapping dei namespace utente, impostare limiti delle risorse e utilizzare filesystem root di sola lettura. Ogni passo include un esempio concreto di configurazione per Docker Compose. Imparerai anche le insidie comuni come i problemi di compatibilità del kernel con i namespace utente e i compromessi sulle prestazioni quando si applica seccomp. Seguendo questa checklist, puoi ridurre significativamente la superficie di attacco senza aggiungere complessità inutili. L'articolo si conclude con una configurazione di base consigliata per ambienti multi-tenant di produzione.
Se gestisci un ambiente Docker multi-tenant, lo spettro di un attacco di fuga dal container ti tiene sveglio la notte. Un singolo exploit del kernel può uscire da un container e dare a un attaccante accesso illimitato all'host e ai dati di tutti gli altri tenant. Sebbene Docker fornisca potenti primitive di isolamento—namespace, cgroups e capabilities—una configurazione errata lascia falle. Questo articolo presenta una checklist di sicurezza passo-passo che puoi applicare oggi. Ogni passo include un frammento funzionante di Docker Compose e avvertenze chiave. Alla fine, avrai una base rafforzata che bilancia sicurezza e prestazioni.
1. Eseguire i Container come Utente Non Root
I container di default vengono eseguiti come root all'interno del container. Se un attaccante ottiene i permessi di root nel container, ha un vantaggio iniziale per fuggire. Definisci sempre un utente non root nel tuo Dockerfile.
FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
In Compose, puoi anche impostare direttamente l'utente:
services:
app:
image: myapp
user: "1000:1000"
Avvertenza: Alcune applicazioni richiedono root per operazioni legittime (ad esempio, il binding a porte inferiori a 1024). Usa CAP_NET_BIND_SERVICE invece di eseguire l'intero container come root. Per un approfondimento sui fondamenti dell'isolamento, consulta la nostra guida su come ottenere un vero isolamento multi-tenant in Docker.
2. Rimuovere Tutte le Capabilities e Aggiungere Solo Quelle Necessarie
Le capabilities Linux concedono privilegi granulari ai container. Di default, Docker assegna un insieme di capabilities. Rimuovi tutto e concedi solo quelle necessarie.
services:
app:
image: myapp
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE # se necessario
Avvertenza: Capabilities come SYS_ADMIN o NET_RAW sono raramente necessarie. Verifica la tua applicazione per determinare l'insieme minimo. Rimuovere tutte le capabilities blocca molti vettori di fuga.
3. Applicare un Profilo Seccomp
Seccomp (secure computing mode) filtra le chiamate di sistema a disposizione di un container. Docker include un profilo seccomp predefinito che blocca syscall pericolose come clone con certi flag. Puoi personalizzarlo ulteriormente.
services:
app:
image: myapp
security_opt:
- seccomp=/path/to/custom-profile.json
Un profilo rinforzato potrebbe bloccare unshare, ptrace e mount. Inizia con il profilo predefinito di Docker e restringi ulteriormente. Avvertenza: Profili eccessivamente restrittivi possono rompere le applicazioni. Testa accuratamente in un ambiente di staging. Per ulteriori informazioni sulle difese contro le fughe dai container, leggi difendersi dalle fughe dai container.
4. Abilitare il Re-mapping dei Namespace Utente
I namespace utente mappano l'utente root del container a un utente host non privilegiato. Questo significa che anche se un attaccante ottiene i permessi di root all'interno del container, non ha privilegi speciali sull'host.
Abilitalo sul demone Docker modificando /etc/docker/daemon.json:
{
"userns-remap": "default"
}
Poi riavvia Docker. Avvertenza: Il re-mapping dei namespace utente ha due svantaggi: interrompe i mount dei volumi se non configurato con attenzione (i file sono di proprietà dell'utente rimappato) ed è incompatibile con alcuni driver di storage come overlay2 su kernel più vecchi. Testa accuratamente.
5. Impostare Limiti delle Risorse con i Cgroups
I limiti delle risorse impediscono a un container compromesso di lanciare un attacco denial-of-service contro l'host. Usa i cgroups per limitare CPU, memoria e I/O del disco.
services:
app:
image: myapp
deploy:
resources:
limits:
cpus: '0.5'
memory: 512M
Per Docker Compose v3, usa la sezione deploy (funziona con swarm o compose v2). Per Docker semplice, usa --memory e --cpus. Avvertenza: Impostare limiti troppo bassi può causare kill OOM. Monitora l'utilizzo e regola di conseguenza.
6. Utilizzare un Filesystem Root di Sola Lettura
Un filesystem root di sola lettura impedisce agli attaccanti di scrivere binari malevoli o modificare file di configurazione all'interno del container.
services:
app:
image: myapp
read_only: true
tmpfs:
- /tmp:noexec,nosuid,size=64m
Monta tmpfs sulle directory che necessitano di accesso in scrittura (come /tmp). Questo forza tutti i dati scrivibili a essere effimeri. Avvertenza: Alcune applicazioni richiedono storage persistente; usa volumi nominati per quello.
Insidie Comuni
- Compatibilità del kernel: Il re-mapping dei namespace utente e alcune regole seccomp richiedono un kernel Linux recente (4.14+). Controlla la versione del tuo kernel.
- Impatto sulle prestazioni: Seccomp e i namespace utente aggiungono un piccolo overhead, ma è trascurabile per la maggior parte dei carichi di lavoro. Fai un benchmark della tua applicazione specifica.
- Complessità: Aggiungere tutte e sei le misure contemporaneamente può rompere le cose. Applicale una per una, testa ogni modifica.
Per una visione più ampia dei pattern di orchestrazione, consulta la nostra guida su progettare un'architettura Docker multi-tenant.
Conclusione
Un host Docker multi-tenant sicuro non richiede strumenti esotici, solo l'uso corretto delle funzionalità integrate di Docker. Inizia con un utente non root, rimuovi tutte le capabilities, applica un profilo seccomp, abilita il re-mapping dei namespace utente, imposta limiti delle risorse e utilizza un filesystem di sola lettura. Questa checklist costituisce una solida base che blocca le tecniche di fuga più comuni. Dopo l'implementazione, esegui strumenti di sicurezza come docker-bench-security per verificare la configurazione. Ricorda: la sicurezza è un processo, non un prodotto. Quando emergono nuove vulnerabilità del kernel, rivedi le tue impostazioni. Per pagine di destinazione automatiche che mostrano il tuo servizio di hosting, usa Pagenza per mettere online il tuo sito in pochi minuti.
Sources (5)
- Docker and Container Isolation
- Chapter 2. Container Hosts and Multi-tenancy | Container Security Guide | OpenShift Container Platform | 3.6 | Red Hat Documentation
- What is Container Escape? - Aqua Security
- Container escape vulnerabilities allow attackers to break out of isolated environments and gain unauthorized access to host systems.
- Enhanced Container Isolation - Docker Docs

