Perché i Container Non Dovrebbero Essere Eseguiti come Root per Impostazione Predefinita?

Eseguire i container come root è una delle più comuni — e più pericolose — misconfigurazioni negli ambienti di produzione. Espande silenziosamente la superficie di attacco di ogni workload, e la maggior parte dei team non se ne accorge finché un incidente non costringe il problema a emergere.

Cosa Significa Realmente "Eseguire come Root"

Per impostazione predefinita, molte immagini di container (soprattutto quelle minimaliste o legacy) eseguono il loro processo principale come UID 0 dentro il container. Poiché i container condividono il kernel host con altri container e l'host stesso, root dentro un container non è lo stesso di root su una macchina virtuale completamente isolata — ma è comunque molto più potente di quanto dovrebbe essere. Se un attaccante ottiene l'esecuzione di codice dentro un container di proprietà di root, ereditano:

• Accesso in lettura/scrittura completo a qualsiasi file montato nel container, indipendentemente dalle autorizzazioni previste
• La capacità di installare pacchetti, modificare binari o manomettere lo stato dell'applicazione
• Un percorso molto più facile verso l'escape del container se una vulnerabilità del kernel o del runtime è sfruttabile
• Una leva maggiore se combinato con volumi mal configurati, come un socket Docker montato o un percorso del filesystem host

Ancora senza un exploit del kernel, l'accesso root dentro il container aumenta drammaticamente il raggio di esplosione di qualsiasi vulnerabilità a livello di applicazione (SSRF, bug di deserializzazione, scrittura di file arbitraria, ecc.).

Perché Questo È Più Importante negli Ambienti Orchestrati

Nei cluster Kubernetes, un container root combinato con capability Linux eccessive o un security context permissivo può consentire a un attaccante di:

• Modificare /proc o /sys in modi che colpiscono l'host
• Escalare i privilegi se hostPID, hostNetwork o hostIPC sono abilitati
• Abusare di un token service account montato per muoversi lateralmente attraverso il cluster
• Sfuggire al nodo se privileged: true è impostato o capability pericolose come SYS_ADMIN sono concesse

L'utente root stesso non è sempre la vulnerabilità — è la combinazione di root più capability del kernel eccessivamente generose, mount host o condivisione di namespace che trasforma un compromesso contenuto in uno a livello di cluster.

Passi Pratici di Hardening

1. Imposta un Utente Non-Root nell'Immagine

Definisci esplicitamente un utente non-root nel tuo Dockerfile piuttosto che affidarti ai default:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. Applicalo a Livello di Orchestrator

Non fidarti solo dell'immagine — applica la policy a runtime. In Kubernetes, usa un securityContext:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true causa il fallimento del pod all'ammissione se l'immagine tenta di eseguire come UID 0, dandoti una garanzia hard piuttosto che una convenzione best-effort.

3. Elimina le Capability Non Necessarie

La maggior parte delle applicazioni non ha bisogno di nessuna delle capability Linux predefinite concesse ai container. Elimina tutto e aggiungi di nuovo solo quello strettamente necessario (rari casi come il binding a porte basse potrebbero aver bisogno di NET_BIND_SERVICE).

4. Evita la Modalità Privilegiata e la Condivisione dello Spazio dei Nomi Host

privileged: true, hostNetwork: true e hostPID: true dovrebbero essere riservati per workload di infrastruttura molto specifici (come certi agent CNI o di monitoring) — mai per container di applicazioni generiche.

5. Scansiona e Applica con Tool Policy

Usa admission controller o policy engine (ad es. Kyverno, OPA/Gatekeeper) per rifiutare automaticamente i deployment che violano queste regole, piuttosto che affidarsi alla code review manuale. Associa questo con la scansione delle immagini in CI per catturare le immagini con utente root prima che raggiungano un cluster.

Una Difesa a Strati, Non Perfetta

Eseguire come non-root non elimina il rischio completamente — gli escape dei container a livello di kernel esistono indipendentemente dall'utente dentro il container — ma rimuove un'enorme classe di tecniche di escalation di privilegi e movimento laterale a basso sforzo. Combinato con filesystem di sola lettura, capability eliminate e policy di rete restrittive, forma uno degli strati più economici ed efficaci in una strategia di sicurezza dei container defense-in-depth.

Vuoi approfondire l'hardening dei workload cloud-native? Esplora i segmenti correlati di Korra Studio su Cloud security e DevOps pipeline hardening per costruire il resto della tua strategia defense-in-depth.