Wayne Starr, technisch lead van het Zarf-team bij Defense Unicorns, beschreef het oorspronkelijke probleem op de Kubelist Podcast: matrozen op onderzeeërs die Linux kennen maar geen Kubernetes, moeten clusters opnieuw deployen als de storage uitvalt tijdens een missie. Geen Docker Hub. Geen Helm-charts downloaden. Geen telefoontje naar DevOps. Zarf is het gereedschap dat uit die beperking voortkwam, en de oplossing voor het registry-bootstrapprobleem is een van de slimste dingen die ik ken in het Kubernetes-ecosysteem.
TL;DR
- Zarf is een open-source airgap package manager die container images, Helm charts en manifests bundelt in één
.tar.zst-archief - Het bootstrapt een in-cluster registry door de registry-image in ConfigMap-chunks te splitsen en met een Rust-binary weer samen te voegen. Geen bestaande infrastructuur nodig
- Een mutating webhook herschrijft image-referenties zodat upstream Helm charts ongewijzigd werken
- Oorspronkelijk gebouwd bij het U.S. Department of Defense (Kessel Run / Platform One), in juni 2024 gedoneerd aan de OpenSSF
- Gesteund door Defense Unicorns ($1B+ waardering, David Petraeus als investeerder), dat verdient via UDS, niet via Zarf-licenties
Inhoudsopgave
- Wat een air gap betekent voor Kubernetes
- Hoe Zarf het bootstrapprobleem oplost
- Wat er na init gebeurt
- Van Kessel Run naar OpenSSF
- Het geld achter Defense Unicorns
- Wat zijn de alternatieven
- Wanneer Zarf niks voor je is
- Belangrijkste punten
Wat een air gap betekent voor Kubernetes
Kubernetes gaat ervan uit dat internet er gewoon is. De kubelet haalt images op van registries. Helm fetcht sub-charts van remote hosts. Flux en ArgoCD reconciliëren tegen remote Git-servers. Init containers downloaden binaries at runtime.
Zet dat uit, en je cluster wordt een duur stuk hardware dat niks doet. Het ergste: je kunt niet eens een container registry deployen, want daarvoor heb je een registry nodig om de registry-image te pullen. Dat kip-en-ei-probleem is waar handmatige airgap-workflows stranden in eindeloos docker save, docker load, handmatig docker tag, docker push naar een lokale registry, en custom Helm-value-overrides per chart. Geen declaratief manifest van wat er in zit. Geen SBOM. Geen signing. Geen manier om differentiële updates te doen. Gewoon een map vol tarballs en een spreadsheet die iemand vergeten is bij te werken.
Wie dit dagelijks meemaakt? Defensie en inlichtingendiensten op geclassificeerde netwerken (IL4/IL5/IL6+), ICS/SCADA-operators op bewust geïsoleerde OT-netwerken, offshore-platforms, nucleaire installaties, ziekenhuizen op afgesloten klinische netwerken, en daadwerkelijk onderzeeërs die om de paar maanden bovenkomen om software-updates te ontvangen via fysieke media.
Hoe Zarf het bootstrapprobleem oplost
ConfigMap-injectie is het hart van het project. Dit doet zarf init op een vers, volledig afgesloten cluster:
- De ~18MB registry-image past niet in de 1MB ConfigMap-limiet. Zarf splitst het in chunks en maakt per chunk een ConfigMap.
- Een statisch gecompileerde Rust-binary (de injector) wordt ook als ConfigMap geladen.
- Zarf kaapt een bestaande pod in het cluster, mount de ConfigMaps, draait de injector, die de chunks samenvoegt en een tijdelijke pull-only registry start.
- Vanuit die tijdelijke registry wordt de permanente
docker-registryHelm chart gedeployed. - De injector ruimt zichzelf op.
Geen bestaande infrastructuur nodig. Geen DaemonSet. Gewoon ConfigMaps en een Rust-binary. Het werkt op k3s, RKE2, EKS, AKS, elke conforme Kubernetes-distributie. De elegantie zit hem erin dat het alleen primitieven gebruikt die elk Kubernetes-cluster gegarandeerd heeft: ConfigMaps en pods.
Voor edge cases waar de standaardaanpak faalt (NFTables-gebaseerde clusters, IPv6-only omgevingen waar NodePort-injectie breekt) is er een alpha proxy-modus die een DaemonSet met socat over host-ports met mTLS gebruikt. Minder elegant, maar het dekt de hoekgevallen.
Wat er na init gebeurt
Als de in-cluster registry eenmaal draait, heeft de Zarf-workflow twee helften.
Op de connected kant: zarf package create leest een zarf.yaml en haalt alles op wat je applicatie nodig heeft in een gecomprimeerd .tar.zst-archief: container images (OCI-formaat), Helm charts met alle sub-chart-dependencies, Git-repositories (voor Flux/ArgoCD-gebaseerde GitOps-workflows, die bij deploy naar een embedded Gitea worden gepusht), Kustomize-overlays (gerenderd tijdens create), raw manifests en willekeurige bestanden. Manifests die geen Helm charts zijn worden in auto-gegenereerde charts gewrapped, zodat Zarf rollback en uninstall uniform via Helm's Go SDK kan beheren.
Op de afgesloten kant: breng het archief over de air gap (USB-stick, beveiligde koerier, geclassificeerde data-diode, wat je securitybeleid ook voorschrijft) en draai zarf package deploy. Images uploaden naar de in-cluster registry, charts worden toegepast, Git-repos pushen naar Gitea.
De mutating webhook is het andere stuk dat dit praktisch maakt. De zarf-agent is een Kubernetes Mutating Admission Webhook die transparant resource-referenties herschrijft bij deploy-time. Pod image-paden worden omgeleid naar de lokale registry. Niet-gepinde tags krijgen een CRC32-hash-suffix (nginx:1.25 wordt nginx:1.25-zarf-298505108) om tag-collisions tussen packageversies te voorkomen. Flux GitRepository, OCIRepository en HelmRepository-objecten worden doorverwezen naar de in-cluster Gitea of OCI-registry. Hetzelfde geldt voor ArgoCD Application- en Repository-objecten. Je deployt upstream Helm charts volledig ongewijzigd. Geen airgap-specifieke forks. Resources kunnen zich afmelden met een zarf.dev/agent: ignore label.
Twee features die extra aandacht verdienen:
Differentiële packages. Met zarf package create --differential <vorige-package> maak je een archief dat images en Git-repos uitsluit die al in de vorige versie zaten. Als je air gap een geclassificeerde koerier met een 64GB USB-stick is, maakt het verschil of je update 20GB of 3GB is.
Automatische SBOM-generatie. Elke zarf package create produceert een Software Bill of Materials, te bekijken via een ingebouwd webdashboard. Dit is geen luxe. Executive Order 14028 verplicht SBOMs voor software die aan de Amerikaanse overheid wordt verkocht. Zarf bakt het in op de packaging-laag, en packages kunnen worden gesigned en geverifieerd met cosign voor deployment. Dit is mede waarom het bij OpenSSF (supply chain security foundation) terechtkwam in plaats van bij CNCF.
Van Kessel Run naar OpenSSF
Het ontstaaansverhaal is relevant omdat het verklaart waarom Zarf werkt zoals het werkt.
Defense Unicorns werd in maart 2021 opgericht door Rob Slaughter (CEO, voormalig directeur van Platform One, PhD in Engineering Physics), Jeff McCoy (CTO, 18+ jaar actieve dienst bij de U.S. Air Force, 551 commits op de Zarf-repo) en Andrew Greene. Hun achtergrond loopt via Kessel Run, een softwarefabriek van de Air Force in Boston die teruggaat tot de Defense Innovation Unit in Silicon Valley rond 2016. Ze bouwden mee aan Platform One en Big Bang (het GitOps-referentieplatform van het DoD), en splitsten zich toen af om het deploymentprobleem op te lossen waar ze steeds tegenaan liepen: hoe krijg je cloud-native software op afgesloten systemen die bediend worden door mensen die geen Kubernetes-experts zijn?
Het antwoord was Zarf. En in juni 2024 doneerde Defense Unicorns het aan de OpenSSF (Open Source Security Foundation), onder de Supply Chain Integrity Working Group. Niet CNCF. Dat is een bewuste keuze: Zarf identificeert zich eerst als supply chain security tooling, en pas daarna als Kubernetes-tooling.
Het project is gezond. LFX Insights laat activiteit zien op 328 van de laatste 365 dagen, 39 actieve contributors per kwartaal, 346 nieuwe PR's per maand, en releases van ongeveer elke twee weken (v0.76.0 verscheen op 14 mei 2026). De governance loopt via een Technical Steering Committee, een ZEP-proces (Zarf Enhancement Proposal), tweewekelijkse community meetings op dinsdag, en de #zarf / #zarf-dev kanalen op Kubernetes Slack.
Het concentratierisico is er wel. Twee contributors bezitten 51%+ van alle commits. Eén organisatie (Defense Unicorns) zit boven diezelfde drempel. Brandt Keller, staff engineer bij Defense Unicorns en Zarf-maintainer, draagt ook bij aan de CNCF Security TAG, wat gezonde kruisbestuiving is. Maar de busfactor blijft krap voor een project dat bewust aan een neutrale foundation is gedoneerd.
Het geld achter Defense Unicorns
Defense Unicorns haalde in januari 2026 $136M op in een Series B (geleid door Bain Capital), en passeerde daarmee de $1B-waarderingsgrens. Andere investeerders zijn onder meer Sapphire Ventures, Valor Equity Partners en David Petraeus (voormalig directeur CIA). Het bedrijf meldde 300% jaar-op-jaar groei in adoptie door militaire systemen.
Het commerciële product is niet "Zarf Enterprise." De monetisatiegrens is helder:
- Zarf (open source, Apache 2.0, gedoneerd aan OpenSSF): de packaging-primitief.
- UDS Core (ook open source, Apache 2.0): een geharde Kubernetes-platform gebouwd op Zarf, met de Pepr policy engine en Lula compliance-automatiseringstool.
- UDS Premium (commercieel): voegt een management-UI, real-time observability en voorverpakte compliancedocumentatie toe voor STIG, CMMC en FedRAMP.
Een UDS Package is een Zarf Package dat UDS Core als runtime target en een UDS Package Kubernetes CRD bevat. De pricing is firm-fixed; DoD-klanten contracteren via een GSA IDIQ-vehicle dat task orders accepteert van DoD, DHS en CISA. Onder SBIR Phase III-autoriteit kan het sole-source worden ingezet.
In juni 2025 lanceerde Defense Unicorns de UDS Registry: een gecureerde registry van geverifieerde, voorverpakte applicaties voor nationale veiligheidsmissies. Zie het als een app store voor militairen die deployen naar onderzeeërs, gevechtsvliegtuigen en geclassificeerde clouds. Ze leveren ook UDS Tactical Edge (UDS uitgebreid naar tactische edge-systemen) en UDS Army. Genoemde klanten op branch-niveau: U.S. Navy, Army, Air Force en Space Force.
Spectro Cloud is momenteel de enige derde partij die Zarf native integreert op platform-UI-niveau. Daarbuiten is het commerciële ecosysteem Defense Unicorns-centrisch. Onafhankelijke consultancybureaus of alternatieve managed service providers kwamen niet naar boven in mijn onderzoek.
Wat zijn de alternatieven
Hauler van Rancher Government Solutions (een SUSE-dochter gericht op de Amerikaanse overheid) is het dichtstbijzijnde open-source alternatief. Het noemt zichzelf de "Airgap Swiss Army Knife" en vermijdt bewust meningen over deployment-workflows. Hauler representeert images, charts en bestanden als OCI Artifacts, slaat ze op in een embedded registry en fileserver, en laat je ze declaratief of ad-hoc verplaatsen. Het bootstrapt geen clusterinfrastructuur, draait geen mutating webhooks en beheert geen Helm-installs. Het heeft wel al v1.0 bereikt (stabiele API); Zarf (v0.76.0, API v1beta1) nog niet.
Als je al een deployment-pipeline hebt en alleen een betrouwbare manier nodig hebt om OCI-content over een air gap te transporteren, is Hauler het eenvoudigere gereedschap. Heb je end-to-end lifecycle management nodig van packaging tot bootstrap tot deployment, dan is Zarf completer.
Replicated lost een heel ander probleem op: ISV's die on-prem Kubernetes-applicaties distribueren naar enterprise-klanten. Het bundelt een K0s-gebaseerde distributie met de applicatie van de vendor als één installer, inclusief airgap-support. De doelgroep is softwaremakers, niet infrastructuurteams.
Gravity van Gravitational (nu Teleport) loste ooit het "cluster als appliance"-probleem op door hele Kubernetes-clusters als .tar-snapshots te verpakken. Het is discontinued. Commentatoren op Hacker News noemden Zarf de spirituele opvolger.
De handmatige aanpak (docker save / docker load / skopeo copy / registry-scripts) bestaat nog overal. Het werkt tot je ~30 images overschrijdt of vaker dan maandelijks updates nodig hebt. Daarna maken de foutpercentages, de ontbrekende SBOMs en de arbeidskosten een dedicated tool onvermijdelijk.
Wanneer Zarf niks voor je is
Als je clusters internettoegang hebben, al is het via een proxy of artifact-mirror, dan heb je het airgap-probleem gewoon niet. Zarf voegt een in-cluster registry, een embedded Gitea-instance en een mutating webhook toe. Dat is overhead die je niet wilt zonder een echte air gap.
De pre-v1.0-status telt mee. Zowel v0.75.0 als v0.76.0 bevatten breaking changes. Het API-schema is nog steeds v1beta1. De eigen roadmap van het project zegt dat er wordt "geïtereerd naar een duurzame baseline die ondersteund kan worden zodra v1.0.0 is bereikt", zonder een streeftdatum te noemen. Bouw je automatisering bovenop Zarf, reken dan op het nauwlettend volgen van upstream releases.
Een vergelijkende analyse op rebelion.la noemde Zarf "een beetje complex in gebruik" en "moeilijk te integreren in een pipeline die al draait in enterprise-projecten." Dat is een eerlijk punt. Zarf is opinionated: je adopteert zijn packaging-model, zijn zarf.yaml-descriptor, zijn init/deploy-lifecycle. Als je organisatie al een beproefde airgap-workflow heeft gebouwd op skopeo en custom scripts, is Zarf daar niet gratis overheen te leggen.
En de concentratie bij Defense Unicorns is het waard om in de gaten te houden. De donatie aan OpenSSF was de juiste governance-stap, maar de contributorgraph leest nog steeds als een single-company project. Voor omgevingen waar onderhoud over decennia telt (precies de omgevingen waarvoor Zarf bedoeld is), hoort dat thuis in je risicoafweging.
Belangrijkste punten
- Zarf is de meest complete open-source oplossing voor deployment naar volledig afgesloten Kubernetes-clusters. De ConfigMap-gebaseerde registry-bootstrap vereist geen bestaande infrastructuur.
- Differentiële packages en automatische SBOM-generatie maken het praktisch voor terugkerende updates via fysieke media, met Executive Order 14028-compliance ingebakken.
- Het is een OpenSSF Sandbox-project, bewust geplaatst onder Supply Chain Integrity in plaats van bij CNCF. De achtergrond van de oprichters loopt via Kessel Run en Platform One.
- Defense Unicorns ($1B+, met Petraeus als investeerder) verdient via UDS, niet via Zarf-licenties. Apache 2.0 blijft overeind. De UDS Registry is een app store voor militairen.
- Hauler is het lichtere alternatief als je alleen content-transport nodig hebt. Zarf is de keuze als je end-to-end lifecycle management wilt.
- Pre-v1.0 met actieve breaking changes. Production-ready voor teams die upstream bijhouden. Als je clusters het internet kunnen bereiken, heb je het niet nodig.