Kubernetes over beveiligingsenclaves: multi-classificatieclusters

Defensieprogramma's opereren zelden op één classificatieniveau. Dezelfde missiesoftware die open-source feeds inneemt in een Unclassified-enclave heeft vaak een Secret-variant die het samenvoegt met gevoelige verzameling, en soms een Top Secret-variant daarbovenop. Het instinct van een ingenieur die gewend is aan commerciële Kubernetes is om deze niveaus te modelleren als namespaces, tenants of virtuele clusters binnen één platform. Dat instinct is verkeerd voor geclassificeerd werk, en het verkeerd doen is kostbaar om ongedaan te maken. In een multi-level secure (MLS) omgeving is het Kubernetes-cluster – en het netwerk waarop het zit – de classificatiegrens, geen tenancy-detail daarbinnen. Dit artikel doorloopt hoe je Kubernetes over beveiligingsenclaves draait: één geaccrediteerd cluster per classificatieniveau, strikte beleidsisolatie binnen elk, verifieerbare image-herkomst en gecontroleerde, eenrichtingspromotie van artefacten tussen domeinen.

De grens is het cluster, niet de namespace

Kubernetes geeft je verschillende mechanismen die op isolatie lijken: namespaces, NetworkPolicies, RBAC, resourcequota's en toelatingscontrole. Elk daarvan is een tenancy-controle die binnen één vertrouwensgrens opereert. Ze delen allemaal dezelfde API-server, dezelfde etcd-datastore, dezelfde Linux-kernel op elke node en dezelfde container runtime. Een container-escape via een kernelkwetsbaarheid, een fout in het autorisatiepad van de API-server of een enkele te brede ClusterRoleBinding kan elk van die zachte grenzen tegelijk passeren.

Een accrediteur die naar een MLS-systeem kijkt stelt een simpele vraag: wat voorkomt fysiek of cryptografisch dat Secret-data de Unclassified-zijde bereikt? "Een NetworkPolicy" is geen aanvaardbaar antwoord, want een NetworkPolicy wordt afgedwongen door dezelfde CNI-plugin en kernel waarop de workloads zelf draaien. Het geaccepteerde antwoord is scheiding: aparte clusters, aparte netwerken, aparte hardware of aparte cryptografisch geïsoleerde partities, elk geaccrediteerd om precies één niveau te verwerken. Namespaces blijven nuttig – maar alleen als administratieve compartimenten binnen één enclave, nooit als de lijn tussen Unclassified en Secret.

Dit is hetzelfde principe dat ten grondslag ligt aan cross-domain-oplossingen voor defensie: data beweegt alleen tussen niveaus via een geaccrediteerde guard, nooit via een gedeelde softwarecontrole die beide zijden kunnen bereiken. Multi-enclave Kubernetes past dat principe simpelweg toe op de orkestratielaag.

Eén cluster per enclave: de referentietopologie

De referentietopologie voor een driedelig programma is drie volledig onafhankelijke Kubernetes-implementaties, één per enclave:

Unclassified- / ontwikkelenclave. Hier vindt het meeste engineering plaats. Het heeft de breedste connectiviteit (vaak een pad naar het internet via een proxy om upstream-afhankelijkheden binnen te halen), de meest tolerante wijzigingscadans en de build-pijplijn die de artefacten produceert die de hogere enclaves uiteindelijk zullen consumeren. Het is nog steeds gehard – standaard-weigerende netwerken, gesigneerde images, geen privileged pods – maar het is de enige enclave waar nieuwe images worden geboren.

Secret-enclave. Losgekoppeld van het publieke internet draait dit cluster de Secret-variant van de missiesoftware. Het haalt images alleen uit zijn eigen in-enclave-register, dat uitsluitend wordt gevuld door promotie van onderaf. De wijzigingscadans is trager en elke implementatie is gekoppeld aan een geaccrediteerde release. De operationele discipline hier lijkt op een air-gapped Kubernetes-implementatie – offline registers, geen live upstream-pulls en een upgradeproces dat accreditatie moet overleven.

Top Secret-enclave. Het meest beperkte cluster, op het meest geïsoleerde netwerk, met de strengste personeels- en fysieke controles. Het ontvangt een gecureerde subset van artefacten van de Secret-zijde, opnieuw alleen via een geaccrediteerde overdracht.

Elke enclave is een compleet, zelfvoorzienend Kubernetes-universum: zijn eigen control plane en etcd, zijn eigen CNI en storage classes, zijn eigen image-register, zijn eigen identity provider en RBAC, zijn eigen GitOps-controller en zijn eigen observability-stack. Niets in een hogere enclave hangt af van de bereikbaarheid van een service in een lagere enclave tijdens runtime. Die onafhankelijkheid is wat elk cluster in staat stelt om op zijn eigen voorwaarden geaccrediteerd te worden.

Waarom federatie over niveaus een verborgen kanaal is

De verleidelijke sluiproute is om identiteit, image-distributie of GitOps over de enclaves te federeren zodat operators één console hebben. Weersta het. Een live authenticatiefederatie die een token uitgeeft dat zowel aan de Unclassified- als de Secret-zijde bruikbaar is, is per definitie een realtime kanaal tussen de twee niveaus – precies het ding dat de scheiding moet voorkomen. De aanwezigheid of afwezigheid van een succesvolle login, de timing van token-vernieuwingen, zelfs foutcodes kunnen informatie over de grens coderen. Dezelfde logica sluit een gedeeld register uit waar beide zijden naar schrijven, of een enkele GitOps-controller die clusters op verschillende niveaus verzoent. Alles wat een synchrone verbinding over de grens onderhoudt, is een potentieel verborgen kanaal en zal de beoordeling niet doorstaan.

Beleidsisolatie binnen elke enclave

Scheiding tussen enclaves is noodzakelijk maar niet voldoende. Binnen elk cluster heb je nog steeds rigoureuze compartimentering nodig, omdat een enclave veel workloads, services en teams host die elkaar niet vrij zouden moeten kunnen bereiken. Dit is waar Kubernetes-native controles hun plaats verdienen.

Begin met toelatingscontrole. Een beleidsengine zoals Kyverno of OPA Gatekeeper dwingt niet-onderhandelbare regels af op het moment dat een workload wordt toegelaten: alleen gesigneerde images uit het eigen register van de enclave mogen draaien; geen pod mag privileged-modus, host-networking of host-path-mounts aanvragen; elke container draait als non-root-gebruiker met een alleen-lezen root-bestandssysteem en een afgeworpen capability-set; en elke namespace voldoet aan het Pod Security Standards restricted-profiel. Dit zijn dezelfde hardeningcontroles die diepgaand behandeld worden in Kubernetes-harding voor defensie-workloads, identiek toegepast in elke enclave zodat de baseline niet tussen niveaus afdrijft.

Netwerken binnen de enclave is standaard-weigerend. Elke namespace begint met een NetworkPolicy die alle ingress en egress laat vallen, en connectiviteit wordt expliciet per servicepaar verleend. Oost-west-verkeer tussen gevoelige compartimenten loopt over mutual TLS, doorgaans via een service mesh, zodat de identiteit van een workload – niet alleen zijn netwerkpositie – de toegang bepaalt. Resourcequota's en limit ranges voorkomen dat een enkele gecompromitteerde of misdragende workload het cluster uithongert.

RBAC en de break-glass-discipline

RBAC binnen elke enclave volgt zonder uitzondering het least privilege-principe. Dagelijkse operators krijgen namespace-gescopete rollen; niemand heeft permanente cluster-admin. De cluster-admin-bevoegdheid leeft achter een break-glass-procedure: een credential dat verzegeld is, waarvan het gebruik een alert triggert en waarvan elke actie wordt vastgelegd in onveranderlijke audit-opslag. Omdat de enclaves onafhankelijk zijn, is de break-glass-procedure dat ook – het gebruiken in de Secret-enclave verleent niets in de Unclassified-enclave. Serviceaccounts zijn beperkt tot één namespace, hun tokens zijn kortlevend en gebonden aan een specifieke workload, en geen ervan wordt ooit hergebruikt tussen clusters.

Image-herkomst: vertrouwen verdiend bij build, geverifieerd bij run

In een multi-enclave-architectuur is de toeleveringsketen het aantrekkelijkste aanvalsoppervlak, omdat een image die eenmaal aan de lage zijde is gebouwd uiteindelijk op Top Secret kan draaien. Elke image moet daarom verifieerbare herkomst dragen die de hoogste enclave kan controleren zonder enige lagere enclave tijdens runtime te vertrouwen.

De discipline is: bouw in de laagste enclave die de image kan bouwen, genereer een volledige software bill of materials (SBOM) in SPDX- of CycloneDX-formaat, scan het tegen een in die enclave gespiegelde kwetsbaarheidsdatabase, en signeer zowel de image als de SBOM met een Sigstore Cosign-sleutel. De handtekening bindt de image-digest aan een bekend buildproces. Elke enclave draait zijn eigen register – Harbor en zot zijn de gangbare keuzes voor losgekoppelde werking – en de toelatingscontroller van elk cluster verifieert de Cosign-handtekening tegen een enclave-specifieke publieke sleutel voordat de image mag draaien. Een ongesigneerde image, of een waarvan de digest niet overeenkomt met het gepromote record, start nooit.

Dit is belangrijk over de grens heen omdat het cluster aan de hoge zijde het register aan de lage zijde niet vertrouwt; het vertrouwt de cryptografische handtekening en de digest die tijdens promotie is vastgelegd. Zelfs als het register aan de lage zijde gecompromitteerd zou zijn nadat een image was gepromoot, zou de hoge zijde elke vervanging weigeren waarvan de digest verschilt van degene die het heeft vastgelegd.

Gecontroleerde promotie tussen domeinen

Promotie is de enige goedgekeurde manier waarop een artefact een enclavegrens passeert, en het is strikt laag-naar-hoog. Het pad loopt via een geaccrediteerde cross-domain-oplossing of, voor de strengste verbindingen, een hardware data diode die fysiek alleen overdracht in één richting toestaat.

De transfer guard doet echt werk, niet zomaar een kopie. Het valideert de image-digest en Cosign-handtekening tegen een allowlist van goedgekeurde artefacten; het inspecteert de SBOM en weigert elke image die een verboden component, een niet-goedgekeurde licentie of een bekend kwetsbaar pakket boven de drempel van het programma bevat; het verwijdert of normaliseert metadata die verborgen data zou kunnen dragen; en het logt de overdracht met de operatoridentiteit, tijdstempel en artefact-digest naar een audit-record aan beide zijden. Pas nadat elke controle slaagt wordt het artefact naar het register aan de hoge zijde geschreven, waar het hoge cluster het kan ophalen.

Verplaatsing van hoog naar laag is de gevaarlijke richting en wordt dienovereenkomstig behandeld. Logs, metrics of build-telemetrie van een Secret-enclave naar een Unclassified-enclave neerhalen is een potentiële spill, dus het is ofwel ronduit verboden ofwel via een aparte, veel strengere beoordeling met menselijke adjudicatie van elk vrijgegeven record gerouteerd. De standaardhouding is dat data omhoog stroomt en boven blijft.

GitOps en operaties zonder de lijn te overschrijden

Elke enclave draait zijn eigen GitOps-controller – Argo CD of Flux – die verzoent tegen een Git-repository die binnen die enclave leeft. De desired-state-manifesten voor de hogere enclave zijn zelf artefacten die omhoog worden gepromoot via de cross-domain-oplossing, op dezelfde manier beoordeeld als images. Dit behoudt het audit-spoor (de repository aan de hoge zijde legt precies vast wat is gepromoot en door wie) zonder ooit een controller over de grens te verbinden.

Observability volgt dezelfde regel. Falco voor runtime-dreigingsdetectie, het Kubernetes-audit-log, Prometheus-metrics en gecentraliseerde container-logs draaien allemaal binnen elke enclave en voeden een enclave-lokale SIEM. Telemetrie stroomt nooit uit een hoge enclave naar een dashboard aan de lage zijde; als een samengevoegd, niveau-overschrijdend operationeel beeld werkelijk vereist is, wordt het gebouwd door beoordeelde samenvattingen omhoog naar de hoogste enclave te exporteren, niet door ruwe telemetrie omlaag te halen. Audit-retentie wordt per enclave ingesteld om aan de accreditatie-eis van die enclave te voldoen, en continue monitoring – kwetsbaarheids-herscans tegen de in-enclave-mirror, drift-detectie, periodieke herverificatie van image-handtekeningen – draait onafhankelijk in elk cluster.

Wat dit kost, en waarom het de moeite waard is

Drie onafhankelijke clusters draaien in plaats van één multi-tenant cluster is werkelijk meer werk: drie control planes om te patchen, drie registers om te vullen, drie identity providers, drie GitOps-pijplijnen en een promotieproces daartussen. Ingenieurs voelen de wrijving elke keer dat een image die aan de lage zijde werkt, gepromoot moet worden voordat het hoger kan draaien. Maar die wrijving is de beveiligingseigenschap, geen gebrek ervan. De promotiepoort is waar herkomst wordt geverifieerd, verboden componenten worden opgevangen en een compleet, onveranderlijk record van wat de grens passeerde wordt gecreëerd. De enclaves samenvouwen tot één cluster om moeite te besparen zou een accrediteerbare, verdedigbare architectuur inruilen voor één gedeelde kernel en API-server die tussen Unclassified en Secret staan – een ruil die geen accrediteur zal accepteren en die geen programma zou moeten willen.

Voor teams die ook de hogere enclaves losgekoppeld moeten houden, koppelen de operationele patronen natuurlijk aan een air-gapped Kubernetes-praktijk: offline registers, gespiegelde afhankelijkheden en een upgradediscipline die geen live pad naar de buitenwereld veronderstelt.