Per milioni di sviluppatori il modo piu’ rapido di provare ClickHouse e’ un singolo docker run, e l’immagine clickhouse/clickhouse-server ha superato i 100 milioni di pull su Docker Hub. Il problema, pero’, non e’ iniziare: e’ quello che succede dopo, quando lo stesso comando che gira sul laptop deve girare in produzione, dentro una pipeline, dietro un team di sicurezza e con un vulnerability scanner che controlla tutto. ClickHouse ha annunciato la disponibilita’ delle proprie Docker Hardened Images (DHI) per rispondere a questo attrito.
Perche’ l’immagine standard viene bloccata
Ogni container e’ fatto di due strati: l’applicazione e il sistema operativo di base. L’immagine standard di ClickHouse e’ costruita su Ubuntu 22.04, che porta con se’ comodita’ (una shell, strumenti di debug) ma anche decine di pacchetti che ClickHouse non usa mai, come Perl, wget e apt. Gli scanner come Trivy, Grype o quello di AWS ECR inventariano ogni pacchetto, che l’applicazione lo carichi o meno. Alcuni di quei pacchetti Ubuntu portano CVE note senza fix upstream: wget, per esempio, spedisce la CVE-2021-31879 senza patch dal 2021. Il risultato e’ un loop frustrante: il database funziona, ma il deploy viene bloccato e si perdono giorni a scrivere eccezioni di rischio per pacchetti che ClickHouse non tocca.
Cosa cambia con le Hardened Images
Ad aprile 2026 Docker ha aggiunto clickhouse-server al suo Hardened Images catalog. Le DHI partono da una domanda diversa: cosa serve davvero a ClickHouse per girare? L’immagine spedisce una base minimale senza package manager e senza strumenti di rete come wget o curl, gira come utente non-root e porta la provenance SLSA Level 3, prova crittografica di cosa e’ entrato nella build. Invece di applicare la patch alla vulnerabilita’ di wget, la DHI rimuove wget del tutto. Nel confronto con Docker Scout, l’immagine standard risultava con 8 finding medium e 11 low su 111 pacchetti, mentre la DHI mostrava 0 medium e 14 low, con i finding residui in librerie core come glibc e openssl dove non esiste un fix in nessuna distribuzione.
Dal punto di vista del database non cambia nulla: volume mount e file di config restano identici e il passaggio richiede una sola riga modificata (con CLICKHOUSE_PASSWORD a rendere il database raggiungibile via rete). Il piccolo scotto e’ che le DHI vivono in un registry separato, quindi vanno mirrorate nel namespace della propria organizzazione. Per il debug, la DHI offre una variante dev con il tooling extra e docker debug collega temporaneamente un set completo di strumenti senza ricostruire l’immagine. Oltre al server, sono hardened anche ClickHouse Keeper, l’operatore Kubernetes con la sua Helm chart e il metrics exporter.
- Le CVE che bloccano i deploy stanno nella base Ubuntu, non in ClickHouse: rimuovere gli strumenti inutilizzati elimina i finding alla radice.
- Il comportamento del database resta invariato; la migrazione e’ una singola riga piu’ l’autenticazione al registry
dhi.io. - Developer experience e sicurezza non sono un trade-off: si irrobustisce cio’ che va in produzione, tenendo gli strumenti di debug in sviluppo.
Fonte: ClickHouse on Docker Hardened Images — https://clickhouse.com/blog/docker-hardened-images
Hai qualcosa da aggiungere? Unisciti alla discussione.