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, monitoring, stack AI locali e automazioni 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 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 rendono sicuro un servizio esposto male, ma offrono ai SysAdmin una base più pulita rispetto a immagini generiche piene 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 concreto è accumulare container dimenticati: immagini vecchie, tag latest, dipendenze vulnerabili, permessi larghi e backup mai provati. Una CVE in una libreria di sistema dentro l'immagine può restare 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;
• metadati utili come SBOM e informazioni di provenienza.

Il vantaggio non è soltanto tecnico. Meno vulnerabilità irrilevanti significa meno tempo perso a interpretare report di scanner pieni di 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 sensato è partire dai servizi stateless o facilmente ripristinabili: job di automazione, exporter, piccoli servizi web interni, tool di test. Eviterei come primo esperimento database, identity provider e componenti 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.

| Tipo servizio | Priorità | Note operative | | --- | --- | --- | | Exporter e utility | Alta | Ottimi per testare immagini minimali | | App web interne | Alta | Verificare variabili, path e permessi | | Reverse proxy | Media | Testare 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, 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:

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:

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 file temporanei o shell specifiche. Per questo il test va fatto con log alla mano, non copiando opzioni da una guida e sperando che vadano bene.

Aggiornamenti, rollback e monitoraggio

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}}'

Dopo il cambio immagine controllo almeno quattro cose: errori applicativi, consumo RAM, permessi sui volumi e comportamento dei backup. Le immagini 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, scegli un servizio non critico e provaci davvero. Non per fare security theatre, ma per scoprire 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/