Docker Hardened Images: guida pratica per homelab e piccole infrastrutture

Le immagini container sono diventate l'unità di distribuzione standard anche fuori dai team di sviluppo: reverse proxy, dashboard, tool di monitoring, stack AI locali, automazioni e servizi interni girano spesso in Docker Compose dentro un homelab o in una piccola infrastruttura aziendale. Il problema è che molte installazioni restano ferme al livello "funziona": si prende un'immagine pubblica, si monta qualche volume, si apre una porta e si passa oltre.

Nel 2026 vale la pena fare un passo in più. Docker ha spinto molto il concetto di Docker Hardened Images, cioè immagini curate, minimaliste, patchate e pensate per ridurre superficie d'attacco e rumore di vulnerabilità. Non sono una bacchetta magica e non trasformano automaticamente un servizio esposto male in un servizio sicuro, ma danno ai SysAdmin un punto di partenza più pulito rispetto alla classica immagine generica piena di pacchetti non necessari.

Perché interessano anche a chi gestisce pochi server

La sicurezza della supply chain non è un tema solo enterprise. In un homelab evoluto o in una piccola rete aziendale, il rischio più concreto è accumulare container dimenticati: immagini vecchie, tag latest, dipendenze vulnerabili, permessi troppo larghi e backup non testati. Una vulnerabilità in una libreria di sistema dentro l'immagine può rimanere lì per mesi, anche se l'applicazione sopra viene aggiornata.

Le immagini hardened puntano a ridurre tre problemi pratici:

• meno componenti installati, quindi meno CVE potenziali;
• aggiornamenti e patch più prevedibili;
• presenza di metadati utili come SBOM e informazioni di provenienza.

Il vantaggio non è soltanto tecnico. Meno vulnerabilità irrilevanti significa anche meno tempo perso a interpretare report di scanner pieni di falsi positivi o pacchetti mai usati dal servizio.

Hardening dell'immagine non significa hardening del servizio

Qui bisogna essere netti: cambiare immagine non basta. Un container basato su un'immagine più sicura può comunque essere configurato male. Se gira come root, monta /var/run/docker.sock, espone porte inutili su Internet o usa segreti in chiaro dentro il Compose, il rischio rimane alto.

Una buona adozione va vista come una catena:

1. immagine di base più piccola e mantenuta;
2. tag versionati, non latest;
3. utente non privilegiato quando possibile;
4. filesystem read-only dove compatibile;
5. capability Linux ridotte;
6. rete segmentata;
7. backup e restore testati;
8. aggiornamento controllato con rollback.

Le Docker Hardened Images aiutano soprattutto sui primi punti. Tutto il resto resta responsabilità di chi gestisce l'infrastruttura.

Dove inserirle in un homelab reale

Non conviene migrare tutto in blocco. Il percorso più sensato è partire dai servizi stateless o facilmente ripristinabili: reverse proxy secondari, job di automazione, exporter, piccoli servizi web interni. Eviterei come primo test database, sistemi di identità o componenti critici del backup.

Il criterio è semplice: se il container fallisce, quanto tempo serve per tornare indietro? Se la risposta è "pochi minuti e ho un backup", è un buon candidato. Se la risposta è "non lo so", prima va sistemata la procedura di restore.

Una matrice pratica:

| Tipo servizio | Priorità | Note operative | | --- | --- | --- | | Exporter e utility | Alta | Ottimi per testare immagini più minimali | | App web interne | Alta | Verificare variabili, percorsi e permessi | | Reverse proxy | Media | Testare bene reload, certificati e plugin | | Database | Bassa | Migrare solo con backup verificato | | Servizi con plugin | Media | Attenzione a shell, CA, librerie mancanti |

Checklist di migrazione

Prima di cambiare immagine in produzione, preparo sempre una checklist breve ma concreta:

• identificare immagine attuale, digest e tag;
• verificare se esiste un equivalente hardened compatibile;
• leggere differenze note: utente, shell disponibile, path, CA certificate, package manager;
• fissare un tag esplicito o un digest;
• creare backup di volumi e configurazioni;
• avviare il container in parallelo su porta diversa;
• controllare log, healthcheck e funzionalità principali;
• eseguire uno scanner come Trivy, Grype o Docker Scout;
• documentare il rollback nel repository del Compose.

Esempio di controlli minimi:

docker compose pull
docker compose config
docker compose up -d nome-servizio
docker compose logs --tail=100 nome-servizio
docker inspect nome-servizio --format '{{.Config.User}}'

Per lo scan, in laboratorio uso spesso un comando del genere:

trivy image --severity HIGH,CRITICAL nome-immagine:tag

L'obiettivo non è arrivare a zero vulnerabilità a tutti i costi. L'obiettivo è capire quali vulnerabilità sono reali per quel servizio, quali dipendono dall'immagine base e quali richiedono un aggiornamento applicativo.

Compose più difensivo

L'immagine hardened rende di più se il Compose non concede privilegi inutili. Un esempio generico:

services:
  app:
    image: vendor/app:1.2.3
    read_only: true
    user: "1000:1000"
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp
    networks:
      - backend
    restart: unless-stopped

Non tutte le applicazioni supportano subito read_only o cap_drop: ALL. Alcune scrivono cache in percorsi imprevisti, altre si aspettano di poter creare file temporanei. Per questo il test va fatto con log alla mano, non copiando opzioni da una guida e sperando che vadano bene.

Aggiornamenti e rollback

Il punto più sottovalutato è il ciclo di aggiornamento. Un'immagine sicura oggi non resta sicura per sempre. Serve una routine: controllare update, leggere changelog, aggiornare in staging o su una VM clone, poi promuovere in produzione. In un homelab basta anche una finestra mensile, ma deve esistere.

Per il rollback conviene salvare sempre il digest precedente:

docker image inspect vendor/app:1.2.3 --format '{{index .RepoDigests 0}}'

Nel file Compose, quando il servizio è critico, preferisco usare tag specifici e annotare il digest testato in un commento. Il digest puro è più rigido e riproducibile, ma meno comodo nella manutenzione quotidiana. La scelta dipende da quanto è critico il servizio.

Cosa monitorare dopo la migrazione

Dopo il cambio immagine controllo almeno quattro cose: errori applicativi, consumo RAM, permessi sui volumi e comportamento dei backup. Le immagini più minimali possono non includere strumenti che alcuni script davano per scontati, come curl, bash o certificati particolari. È meglio scoprirlo subito che durante un incidente.

Un buon criterio è lasciare il vecchio container fermo ma non rimosso per qualche ora o giorno, mantenendo intatti volumi e configurazione precedente. Se qualcosa non torna, il rollback deve essere banale: ripristino Compose, pull dell'immagine precedente, up -d, verifica healthcheck.

Conclusione

Le Docker Hardened Images sono interessanti perché portano nel mondo container una disciplina che i SysAdmin conoscono bene: partire da una base minima, patchata e verificabile. Per DanpLab il punto non è inseguire ogni novità, ma trasformarla in una procedura ripetibile: inventario, test, scan, migrazione graduale e rollback.

Se gestisci un homelab serio o una piccola infrastruttura, il consiglio pratico è scegliere un servizio non critico questa settimana e provarci davvero. Non per "fare security theatre", ma per capire quali assunzioni nascoste hanno i tuoi container: permessi, filesystem, dipendenze e processi di aggiornamento. È lì che di solito si trova il debito tecnico.

Fonti

• Docker Hub e catalogo immagini container: https://hub.docker.com/
• Docker Hardened Images, panoramica e discussione pubblica: https://thenewstack.io/dockers-sets-free-the-hardened-container-images/
• Aqua Trivy vulnerability scanner: https://github.com/aquasecurity/trivy
• Docker Compose file reference: https://docs.docker.com/reference/compose-file/