Docker maakt 'hardened' images met extra beveiliging gratis voor iedereen

Docker Hardened Images komen gratis beschikbaar voor iedereen. Het gaat om een catalogus van ruim duizend Docker-images die extra beveiligingsmaatregelen meekrijgen. DHI's werden eerder dit jaar geïntroduceerd tegen betaling.

Docker bevestigt dat de volledige catalogus van hardened images gratis beschikbaar komt voor alle Docker Hub-gebruikers. Alle images worden volgens het bedrijf ook opensource onder een Apache 2.0-licentie. Gebruikers van 'gewone' Docker-images kunnen gemakkelijk upgraden naar hun hardened varianten, indien die beschikbaar zijn.

Docker Hardened Images werden in juli geïntroduceerd. Volgens het bedrijf zijn ze 'tot 95 procent' minder gevoelig voor kwetsbaarheden dan gewone Docker-images. Ze gebruiken onder andere een distrovrije runtime voor een kleiner aanvalsoppervlak.

Iedere image wordt ook voorzien van een 'software bill of materials', oftewel een lijst van alle componenten en dependency's binnen de image. Ze bieden ook een cryptografische proof of authenticity, SLSA-niveau 3 voor een sterkere bescherming tegen manipulatie en andere toevoegingen die de beveiliging ten goede moeten komen. Er zijn meer dan duizend DHI's beschikbaar, onder andere voor images als .NET, Node.js, PostgreSQL en Python.

Reacties (31)

[olafmol]

Dit is wel een biggy, bedrijven als Chainguard zullen hier wel last van krijgen vermoed ik.

Onze CTO (ik werk bij CircleCI, een global dedicated CI/CD platform) staat ook met een quote in de Docker press release. Hij vertelde dat gisteren ongeveer het hele leadership-team van Docker bij ons op het kantoor was (president, CRO, VP eng etc.) en dat dit dus echt wel een belangrijke stap voor Docker is.

Voor ons als CICD platform is het ook zeker interessant. Wij onderhouden zelf een hele lading secured/hardened "convenience images" (https://circleci.com/developer/images) en we gaan nu samen met Docker onderzoeken hoe we dit DHI initiatief het beste kunnen inzetten, zowel intern als als images voor het CICD platform.

Er was een tijd dat Docker het zwaar had (bv na het vertrek van cofounder Solomon Hykes) maar ze lijken het toch wel weer rechtgetrokken te hebben. Ben benieuwd.

[OB1]

Ik ben benieuwd of het als een drop-in replacement zal gaan functioneren... vermoedelijk wel met een paar kanttekeningen!

Distroless images hebben (onder andere) geen shell of bijv. package managers, wat inderdaad de attack surface verlaagt, maar logischerwijs er ook voor zorgt dat applicaties die tijdens runtime hier gebruik van maken niet zullen werken. Ook is het opsporen van fouten in containers lastiger omdat je niet 'even' een SSH-sessie kunt starten.

Een aanvullend voordeel van distroless images is dat deze kleiner zijn (want er zijn simpelweg minder tools aanwezig). Wat netwerkverkeer reduceert tijdens het pushen en pullen van de images van/naar de registry. Hierdoor zullen je deployments versnellen en worden kosten voor de infrastructuur (marginaal) verlaagd.

Lijkt mij tof om hier binnenkort met mijn home server mee aan de slag te gaan!

[ptap480]

Een shell in een container is leuk voor development, maar in productie moet je dat niet willen. Het is tenslotte geen VM. Voor software downloads en compilen Kun je gewoon een multi-stage build van het image doen, waarbij je alle niet run-time benodigde zaken in de build image achter laat.

Ik Heb laatst, als demo een lege container image (15K) gemaakt (buildah from scratch), die ik gebruik om een in een build stage gebouwde "Hello World" (in C of in Rust) in te plaatsen. Zo'n container images is dan maar een een paar MB groot en doet precies wat het moet doen en niet meer. De uitdaging zat 'm vooral in de static linking. Ik ben dat nu voor een python omgeving aan het proberen, maar ondanks de documentatie van python zelf, krijg ik die nog niet helemaal aan de gang. Gelukkig komt de Kerst ER aan :-)

Uiteindelijk is een (Linux) container niet meer dan een gewoon Linux process met filesystem en process isolatie en dus moet je proberen zoveel mogelijk ballast buiten het image te houden.

[Mars Warrior]

Een shell in een container is leuk voor development, maar in productie moet je dat niet willen. Het is tenslotte geen VM.

Hoezo niet?

Veel apps hebben een eigen CLI die ik in ieder geval veel gebruik. vziw vereist dat toch dat ik via een shell in de container moet kunnen komen via docker exec.

Verder zijn er nogal wat Docker containers die in werkelijkheid omgebouwde VMs zijn (100 processen of meer), en die zijn zonder shell toegang of eigen CLI totaal nutteloos zijn om te gebruiken.

Wat ik overigens bij dit soort "hardening" altijd mis is feitelijke cijfers. Tot 95% is nikzeggend. Dat het aanvalsoppervlak kleiner is dat is zeker een verkleining van de kans op problemen. maar hoevaak veroorzaken gaten in de images (oude libraries, whatever) nu problemen, en kun je aantonen dat dat bij de hardened images dan niet had kunnen gebeuren?

[ptap480]

Voor dit soort applicaties zou ik dan een server container image maken en een client image met de tools. Met een (intern) network Kun je Dan prima met die tools bij de server, zonder dat de server all die dingen aan boord heeft. Dat client instance spin je dan alleen op als je het nodig hebt. De server/service kan continue draaien.

[Mars Warrior]

Dat is zeker voor sommige apps mogelijk, maar de meeste die ik gebruik, gebruiken zelf ook de CLI om functies uit te voeren, dus scheiden is redelijk kansloos

Verder kan ik werkelijk nergens ook maar 1 voorbeeld vinden wat DHI heeft weten te voorkomen. Docker bezigt voornamelijk management termen, en dan gaat het voornamelijk over SLA's en andere beweringen over supply-chain-attacks die in de regel niets te maken hebben met Docker images.

De ontwikkeling op zich is mooi, maar als ik nu een docje zou moeten maken voor de directie zou ik absoluut niet weten wat ik concreet (kosten, onderhoud) daarin zou moeten zetten als business case.

De vraag "Noem eens een voorbeeld wat we dan niet meer hoefven te doen en/of voorkomen" kan ik namelijk vanuit de praktijk al niet eens beantwoorden!

[ptap480]

Dit is natuurlijk niet zo 1 2 3 te beantwoorden. Ik ga hier uit van source to image deployment en dan zie ik dit als de security technisch meest optimale deployment. Daarmee zeg niet dat dat functioneel/financieel de meest optimale is; dat is aan de organisatie die het wil gebruiken.

Ik geef les in container development en omdat ik daar zie dat iedereen vrijwel klakkeloos de standard building blocks pakt, zonder na te denken over wat je werkelijk probeert te bereiken met containers, heb ik deze voorbeelden gebouwd. Tot nu toe zie ik vooral verassing bij de ontwikkelaars in mijn klassen (oh, dat wist ik niet, dat dat zo kan) en waardering bij de meer beheer georienteerde mensen.

Het prikkelen van het nadenken over problem/oplossing is wat ik er mee hoop te bereiken, zonder dat ik ga roepen dat ik de waarheid in pacht heb. Zeker niet. Dat geldt, bij deze trainingen, ok voor het gebruik van unprivileged accounts in containers, etc. waarom beter, waar zitten de uitdagingen, etc.

[sjongenelen]

Het voorkomt onderhoud door eigen IT? Hardening wordt meestal uitgevoerd door het bedrijf. Met deze images ben je al een flinke stap

[YopY]

Voor die use cases zul je natuurlijk een wat uitgebreidere image moeten gebruiken, maar over het algemeen is het beter om alles wat op het internet bereikbaar is zo klein mogelijk te houden. Wat ook al door iemand anders gezegd werd, scheiding tussen client / server containers maken.

[jorisvergeerTBA]

Die CLI is toch ook gewoon met docker exec aan te roepen. Daar heeft de docker container toch geen volle bash environment of package manager voor nodig?

En wat is er mis met meerdere processen in docker? Een VM draait een gevirtualiseerd OS. Een docker container bevat idealiter alleen de runtime die nodig is om in een gesloten omgeving binnen de host OS te draaien.

PostgreSQL bijv. draait een process per connectie, elke connectie naar de database krijgt zijn eigen worker process. Als jij 100 connecties hebt, heb je ook 100+ processen draaien in je docker container. Dat maakt het niet minder docker waardig.

[Carnifex]

Precies dit.

Met Golang gaat dat overigens ook heel goed. Zelfs cross-compilen naar ARM, op een X86 machine. Levert een image van een paar mb en doet alleen wat het moet doen. Het liefste heb je ook maar 1 proces actief in je container. Zo heb je op een kleine VM ineens heel veel plek voor containers.

Maar dit is vooral voor software die je zelf bouwt. Op het moment dat je een container wil toevoegen met een database, of andere 'dienst' die je in andere containers wil gebruiken, is het wel fijn als hiervoor minimale implementaties voor zijn (alleen log en de poorten die horen bij de dienst).

Daarnaast zou je ook het host-OS minimaal en immutable willen: alleen containers runnen/beheren, dus zonder te veel zaken die je niet 'nodig' hebt. Dan kom je toch al wel weer snel richting tools als kubernetes, om een vm/host te kunnen updaten, moet je dan eerst een nieuwe starten, containers verplaatsen en de oude verwijderen als alles OK is.

Uiteindelijk wil je een oplossing die werkt en veilig genoeg is. Als je alles helemaal 'goed' wil doen, kost je dat veel effort in tools en setup. Dat kan ook overkill zijn, als je alleen een containertje met iets simpels wil draaien.

[TheDevilOnLine]

Soms wel, vaak net niet. Zo heeft de node DHI bijvoorbeeld geen npm/yarn, daar hebben ze een aparte dev package voor. Met multi step builds kan je die dan "combineren", door in een build container je dependencies te installeren en vervolgens de benodigde spullen over te kopiëren naar de uiteindelijke image.

Van alle veel gebruikte images zijn wel uitgebreide guides beschikbaar over hoe je naar ze toe kan migreren. Zie bijvoorbeeld https://hub.docker.com/hardened-images/catalog/dhi/node/guides

[YopY]

Het is denk ik zeker belangrijk om ook voor jezelf de scheiding te maken tussen 'dev' en 'prod' containers, dev zijn dingen die je voor je CI gebruikt of voor binnen je OTAP straat, 'prod' is voor acceptatie en vooral productie.

Als je statistieken wilt verzamelen kun je altijd een losse container opstarten waar een percentage van requests naartoe gaat; die requests zullen wat langzamer gaan, maar dan krijg je wel genoeg statistische gegevens binnen.

En als je echt SSH toegang enzo wilt tot een productieserver, ten eerste, er is iets mis in je proces. Maar wat je kunt doen om het toch veilig te houden is requests opslaan en / of dupliceren naar een container die verder niet via het internet te bereiken is. Maar als je daar als developer bij kunt moet je heel voorzichtig zijn met PII.

[satya]

Als je het thuis of professioneel draaid, dan zou je coroot kunnen proberen als monitoring tool zodat je toch metrics en logging hebt.

Omdat alles via eBPF loopt belast het je containers ook niet met extra resources voor logging.

[Stetsed]

Eerlijk gezegt vindt het interessant, en ik denk dat voor sommige van mijn componenten in de homelab ik ze well zou gebruiken inplaats van dat ik dit soort dingen in mijn eigen images moet doen. En hoewel ik docker hub nu zoveel mogelijk probeer te vermijden door de rate limit, zal ik hier zeker naar kijken

[Reactie gewijzigd door Stetsed op 18 december 2025 11:12]

[Hieronymuski]

Ik ben toch wel benieuwd wat voor homelab jij hebt als je voor privegebruik 100 tot 200 images per 6 uur naar binnentrekt.

[DennusB]

Eindelijk wat stappen dit vlak, je kon wel een berg geld stuk slaan op iets als ChainGuard, maar dit gratis aanbieden is een super goede volgende stap!

[Stetsed]

Dit is de eerste keer dat ik van chainguard hoor, en hoewel het goed lijkt is mijn grootste probleem dat in de gratis plan ze alleen ondersteuning hebben voor :latest tag, wat zeker voor applicaties is die core draaien niet echt bruikbaar is want dat betekent dat je ook niet kan filteren op basis van major semver, wat kan betekeken dat je niet automatisch minor semver kan patchen wat dan een security probleem kan zijn als je dit handmatig moet doen.

Edit: Ik zie nu dat ze het een beetje fout hebben gezet, blijkbaar heb je daar ook access tot semver tags voor een set aan images, dus ik zal er zeker naar moeten kijken.

[Reactie gewijzigd door Stetsed op 18 december 2025 11:18]

[Mikero]

Proberen ze hiermee misschien het gat te vullen dat Bitnami heeft achter gelaten sinds 28 augustus?

[TheDevilOnLine]

Dat denk ik niet. De bitnami images liepen vaak achter qua updates en bevatten veel meer vulnerabiltities dan de officiële images.

[Baardmeester]

Dit is toch puur voor de images en werkt dan ook op podman?

[Stetsed]

Correct, dit zijn gewoon OCI images dus zouden gewoon op podman moeten werken

[Ro-Maniak2]

Bbn of Synology dit dan ook gaat brengen in “Comtainer manager” - hun syno branded Docker. Sinds Docker zelf op (iig) de oudere Syno’sniet meer draait.

Of is dat niet gewoon een port/is dit echt Docker branded…

[Mr_gadget]

Dat heeft volgens mij meer te maken of je een bepaalde processor hebt. Docker wordt vooral op intel processors ondersteund. En op duurdere modellen. Dit is meer een strategische keuze van ze.

Ben benieuwd of deze containers gebruikt gaan worden voor een hoop populaire packages.

[TheDevilOnLine]

Wat in het artikel nog mist is dat er ook hardened helm charts beschikbaar zijn voor kubernetes gebruikers, bijvoorbeeld van Traefik en HAProxy.

[MOmax]

Mooie stap van docker met het oog op de CRA, vooral de SBOMs. Ik ga zelf eens zoeken of EMBA ( https://github.com/e-m-b-a/emba ) ook gebruikt kan worden om dergelijke images kan controleren op CVEs en andere vulnerabilities.

Of is er al iemand die dat weet?

[drdextro]

Na het debacle met Bitnami en hun push voor betaald hardend images. Is dit welkome concurrentie.

[YopY]

Het is zowel goed als jammer. Hardened images (of dependencies, of distros, etc) zijn dingen waar de grote enterprises (met veel geld) vraag naar (zouden moeten) hebben en budget voor hebben.

Maar tegelijkertijd is het niet per se super gespecialseerde of geheime kennis om zoiets aan te bieden, dus er is veel concurrentie... en met gratis valt moeilijk te concurreren.

(deze kant zal het ook met AI zaken op gaan, ja je kunt X per maand aan ChatGPT betalen maar hey er is een ander die ongeveer hetzelfde doet maar dan gratis!)