Kubernetes voor defensiewerklasten: orkestratie van geclassificeerde gecontaineriseerde applicaties

Containerorkestratie is het dominante implementatiepatroon geworden voor moderne defensiesoftware, maar de operationele beveiligingsvereisten van geclassificeerde omgevingen leggen beperkingen op die standaard Kubernetes-configuraties niet standaard aanpakken. Een standaard kubeadm-opgestart cluster stelt niet-geverifieerde kubelet-API's bloot, slaat Secrets op als platte tekst in etcd, past geen netwerkbeleid toe tussen pods en genereert auditlogs die noch worden doorgestuurd noch beschermd zijn tegen manipulatie. Elk van deze standaardinstellingen is een bevinding in elke serieuze beveiligingsbeoordeling. Dit artikel behandelt wat nodig is om Kubernetes correct te laten draaien in een geclassificeerde omgeving: van node-hardening tegen CIS- en STIG-basislijnen via HSM-ondersteund secretenbeheer, netwerkmicrosegmentatie, auditlogarchitectuur, supply chain-controles voor images en het documentatietraject naar een exploitatievergunning.

Waarom containerorkestratie belangrijk is voor de implementatie van moderne defensiesoftware

Defensiesoftware is van oudsher geïmplementeerd als monolithische applicaties op toegewijde fysieke servers, waarbij elke systeemupgrade handmatige coördinatie over meerdere beveiligingsdomeinen vereiste en uitgebreid hertesten voordat een wijziging een operationele omgeving bereikte. Containerorkestratie keert dit model om: applicaties worden verpakt als onveranderlijke images, infrastructuur wordt gedeclareerd als code, en de orkestrator beheert planning, statuscontrole en rollende updates over een vloot van knooppunten. Voor programma's die capabiliteitsupdates in weken in plaats van jaren naar operators moeten pushen, is deze verschuiving niet optioneel.

Kubernetes biedt aanvullende voordelen die specifiek relevant zijn voor geclassificeerde werklasten. Isolatie van resources op naamruimteniveau stelt meerdere applicaties op hetzelfde classificatieniveau in staat om knooppuntinfrastructuur te delen zonder elkaars CPU-, geheugen- of netwerkresources te verstoren. Resourcequota's voorkomen dat een misbehaving werklast alle clustercapaciteit verbruikt. Pod-onderbrekingsbudgetten dwingen beschikbaarheidsbeperkingen af tijdens onderhoudvensters. Deze controles mappen direct op de betrouwbaarheids- en isolatievereisten die autoriserende functionarissen verwachten te zien gedocumenteerd in een Systeembeveiligingsplan.

De uitdaging is dat het Kubernetes-project is ontworpen voor op internet gerichte commerciële cloudomgevingen, en de standaardconfiguratie weerspiegelt dat erfgoed. Defensieprogramma's die Kubernetes adopteren, moeten de standaardconfiguratie behandelen als uitgangspunt voor hardening, niet als een aanvaardbare basislijn. De kloof tussen een standaardcluster en een accreditatieklaar cluster is substantieel, maar is goed gedocumenteerd door DISA en het Center for Internet Security, en is overbrugbaar met doelbewust configuratiewerk.

Node-hardening: CIS-benchmarks en STIG-naleving voor Kubernetes-werknemersknooppunten

Node-hardening begint op de laag van het besturingssysteem voordat een enkel Kubernetes-component is geïnstalleerd. Werknemersknooppunten moeten worden gebouwd vanuit een STIG-geharde of CIS Level 2-basisimage -- Red Hat Enterprise Linux CoreOS (RHCOS) voor op OpenShift gebaseerde clusters, of een geharde Ubuntu- of Rocky Linux-build voor upstream Kubernetes. De configuratie van het basis-OS bestrijkt bestandssysteempartitionering (afzonderlijke /tmp-, /var-, /var/log-mounts), kernelparameterhardening (het uitschakelen van IP-forwarding behalve waar vereist door de CNI, het inschakelen van syncookies, het uitschakelen van IP-bronrouting), verplicht toegangsbeheer (SELinux in afdwingmodus of AppArmor-profielen) en verwijdering van onnodige pakketten en services.

Op de Kubernetes-laag convergeren de DISA STIG voor Kubernetes en het CIS Kubernetes Benchmark Level 2 op een kernset van kubelet-configuratievereisten. De kubelet alleen-lezen poort moet worden uitgeschakeld (--read-only-port=0). Anonieme authenticatie moet worden uitgeschakeld (--anonymous-auth=false). De autorisatiemodus moet worden ingesteld op Webhook, waarbij alle autorisatiebeslissingen worden gedelegeerd aan de RBAC-engine van de API-server in plaats van knooppuntlokale beslissingen te vertrouwen. Certificaatrotatie moet worden ingeschakeld zodat kubelet-clientcertificaten automatisch worden vernieuwd voor het verstrijken. De containerruntime -- containerd of CRI-O -- moet worden geconfigureerd met een standaard seccomp-profiel (RuntimeDefault) toegepast op alle pods, tenzij ze expliciet een meer toegestaan of aangepast profiel vereisen.

Het uitvoeren van kube-bench, de open-source CIS-benchmark-auditor, tegen een geconfigureerd cluster produceert een gestructureerd nalevingsrapport in XCCDF-formaat. Dit rapport is een vereist bijlage in de meeste accreditatiepakketten. Categorie I (hoge ernst) bevindingen moeten worden opgelost voor indiening; Categorie II-bevindingen moeten worden opgelost of gedocumenteerd met compenserende controles. Geautomatiseerde herstelplaybooks -- Ansible of vergelijkbaar -- die de benchmarkcontroles reproduceerbaar toepassen op alle knooppunten, hebben sterk de voorkeur boven handmatige configuratie, zowel omdat ze configuratiedrift verminderen als omdat ze controleerbare wijzigingsrecords produceren.

Handhaving van netwerkbeleid: microsegmentatie tussen geclassificeerde werklasten

Standaard kunnen alle pods in een Kubernetes-cluster communiceren met alle andere pods, ongeacht de naamruimte. Dit platte netwerkmodel is geschikt voor ontwikkelomgevingen maar onaanvaardbaar voor geclassificeerde werklasten, waarbij het principe van minimale toegang moet gelden voor netwerkverkeer, net zoals voor RBAC-machtigingen. Het afdwingen van netwerksegmentatie vereist twee dingen: een CNI-invoegtoepassing die de Kubernetes NetworkPolicy-specificatie implementeert, en een set NetworkPolicy-objecten die de toegestane communicatietrajecten definiëren.

Het basishardingpatroon is een standaard-weiger-alles-beleid toegepast op elke naamruimte bij cluster-bootstrap. Dit beleid weigert al het inkomende en uitgaande verkeer tenzij een expliciete toestemmingsregel het toestaat. Expliciete toestemmingsregels worden vervolgens toegevoegd voor elk vereist verkeerspad: DNS-resolutie (TCP en UDP poort 53 naar CoreDNS in kube-system), statuscontrolverkeer van de kubelet naar applicatiecontainers, en toepassingsspecifieke service-naar-service-communicatie. Elke toestemmingsregel moet zo nauw mogelijk worden afgebakend -- door pod-labelkiezer, naamruimtelabelkiezer en poort -- in plaats van brede CIDR-bereiken te gebruiken die een auditorbeoordeling doorstaan maar feitelijk geen laterale verplaatsing beperken.

Voor werklasten op verschillende classificatieniveaus die op gedeelde infrastructuur moeten coëxisteren, is op labels gebaseerd NetworkPolicy alleen onvoldoende. De CNI-invoegtoepassing handhaaft beleid in de netfilterlaag van de Linux-kernel, en een voldoende bevoegde gecompromitteerde container kan netfilter omzeilen. Defensieprogramma's die werklasten op meerdere gevoeligheidsniveaus op één cluster hosten, moeten elk gevoeligheidsniveau in een toegewijde knooppuntpool plaatsen met toegewijde netwerkinterfaces of VLAN's, en cross-laag verkeerscontroles afdwingen op de hardware- of hypervisorlaag. Defensie cloud-interconnectarchitectuur biedt de fysieke en logische scheiding die alleen-beleid-controles niet kunnen garanderen op gedeelde kernelinfrastructuur.

Secretenbeheer: Kubernetes integreren met HSM-ondersteunde sleutelopslag

Kubernetes Secrets worden standaard opgeslagen in etcd als base64-gecodeerde waarden zonder versleuteling. Elke gebruiker of elk proces met leestoegang tot etcd -- of met voldoende RBAC-machtigingen om kubectl get secret aan te roepen -- kan de platte tekstwaarde ophalen. Voor geclassificeerde omgevingen is dit geen configuratiekloof; het is een fundamenteel architectureel probleem dat moet worden opgelost voordat gevoelige gegevens in het cluster worden opgeslagen. De oplossing is etcd-versleuteling in rust met behulp van een KMS-provider die sleutelbeheer delegeert aan een HSM-ondersteunde sleutelopslag.

De kube-apiserver EncryptionConfiguration-resource specificeert een lijst van versleutelingsproviders voor elk resourcetype. Voor de kms-provider verwijst de configuratie naar een Unix-socket waar een KMS-pluginproces luistert. De plugin vertaalt het Kubernetes KMS gRPC-protocol in aanroepen naar de HSM of sleutelbeheerservice -- doorgaans via PKCS#11 voor een netwerk-gekoppelde HSM, of via de sleutelbeheer-API van een defensiekwaliteit cloud KMS. Wanneer de API-server een Secret naar etcd schrijft, roept het de KMS-plugin aan om de gegevensversleutelingssleutel (DEK) te versleutelen onder de HSM-gehouden sleutelversleutelingssleutel (KEK). Alleen de omhulde DEK wordt in etcd opgeslagen naast de versleutelde tekst. Ontsleuteling vereist een retourtrip naar de HSM. De HSM moet FIPS 140-2 niveau 3 gevalideerd zijn voor werklasten op GEHEIM-niveau; niveau 2 is over het algemeen alleen aanvaardbaar voor GEVOELIG maar NIET-GECLASSIFICEERD materiaal.

Auditlogging: API-servergebeurtenissen vastleggen voor naleving en forensisch onderzoek

De Kubernetes API-server genereert een auditlog van elk verzoek dat het verwerkt: wie het verzoek heeft gedaan, welk werkwoord en resource betrokken waren, welke naamruimte, of het verzoek is geslaagd, en -- afhankelijk van het geconfigureerde auditniveau -- de volledige aanvraag- en antwoordtekst. Dit log is het gezaghebbende record voor het beantwoorden van de vraag "wie deed wat in dit cluster en wanneer." Voor geclassificeerde omgevingen is uitgebreide auditlogging niet optioneel; het is een specifieke controlelvereiste in RMF, JSIG en gelijkwaardige kaders, en de afwezigheid van adequate auditlogs is typisch een showstopper-bevinding tijdens een accreditatiebeoordeling.

Het auditbeleid is een YAML-bestand dat bij het opstarten aan de kube-apiserver wordt doorgegeven en resourcetypen en werkwoorden koppelt aan auditniveaus. De vier niveaus zijn None (geen logging), Metadata (gebruiker, werkwoord, resource, status -- geen tekst), Request (voegt de aanvraagtekst toe) en RequestResponse (voegt zowel aanvraag- als antwoordteksten toe). Een nalevingsklasse beleid legt RequestResponse vast voor Secrets, ConfigMaps, Roles, RoleBindings, ClusterRoles, ClusterRoleBindings en ServiceAccounts -- de resources waarvan de wijziging kan duiden op escalatie van bevoegdheden of diefstal van referenties. Pod exec- en attach-aanroepen moeten ook worden vastgelegd op RequestResponse-niveau, omdat dit de primaire vectoren zijn voor interactieve laterale verplaatsing in een gecompromitteerd cluster. Alle andere resources kunnen worden gelogd op Metadata-niveau, wat een volledig toegangsrecord produceert zonder de opslagoverhead van het vastleggen van elke applicatielading.

Auditlogs die alleen op het control-plane-knooppunt zijn opgeslagen, zijn kwetsbaar voor manipulatie door een gecompromitteerde clusterbeheerder. Een defensiekwaliteit auditarchitectuur verzendt logs naar een externe bestemming waarnaar het cluster zelf niet kan schrijven of verwijderen: een SIEM (security information and event management-systeem), een alleen-toevoegen S3-compatibele objectopslag met object-lock bewaarplicht, of een speciale syslog-forwarder naar een air-gapped logaggregatie-infrastructuur. De logverzender -- een Fluentd of Fluent Bit DaemonSet op control-plane-knooppunten -- moet worden uitgevoerd met een Kubernetes-serviceaccount dat geen machtigingen heeft op de te loggen clusterobjecten, zodat een gecompromitteerde verzender zijn eigen sporen niet kan wissen door het auditbeleid te wijzigen of logbestanden te verwijderen.

Imagescanning en supply chain-beveiliging in geclassificeerde containerregisters

Elke containerimage die wordt geïmplementeerd in een geclassificeerd cluster is een potentieel supply chain-aanvalsoppervlak. Een image die van een openbaar register wordt opgehaald zonder inspectie kan bekende kwetsbare bibliotheekversies, ingesloten referenties of kwaadaardige code bevatten die tijdens de buildpijplijn is geïntroduceerd. Defensieprogramma's moeten een privécontainerregister beheren dat is geïsoleerd van het openbare internet, geverifieerde toegang vereist en kwetsbaarheidsscanning en imageondertekening afdwingt voordat een image wordt toegelaten tot het cluster.

Imagekwetsbaarheidsscanningtools zoals Trivy of Grype analyseren elke imagelaag aan de hand van de OSV-adviesdatabase en leveranciersbeveiligingsbulletins, waarbij een lijst van CVE's wordt geproduceerd met ernstigheidsscores en getroffen pakketversies. In een geclassificeerde CI-pijplijn wordt scanning uitgevoerd als onderdeel van het imagebuildproces; images die kritieke of hoge-ernst CVE's bevatten, worden geblokkeerd van het productieregister totdat de kwetsbaarheden zijn opgelost of formeel als risico's zijn geaccepteerd. De scanresultaten worden opgeslagen naast de image in de registermetadata en worden in het accreditatiebewijspakket aangehaald als bewijs dat de software-inventaris bekend en beoordeeld is.

Imageondertekening voegt een cryptografische bewering toe dat een specifieke image-digest is geproduceerd door een specifieke buildpijplijn en niet is gewijzigd sinds de ondertekening. Het cosign-tool van het Sigstore-project ondersteunt ondertekening met een sleutel die is opgeslagen in een HSM of KMS, waarbij een handtekeningbevestiging wordt geproduceerd die naast de image in het register is opgeslagen. De Kubernetes-admissiewebhook -- met behulp van een beleidsengine zoals Kyverno of OPA Gatekeeper -- verifieert de handtekening voordat een pod wordt ingepland. Deze bewakingsketen van build tot implementatie is precies wat supply chain-beveiligingskaders vereisen: elke werklast die in het cluster draait, kan worden herleid tot een specifiek ondertekend buildartefact, en niet-ondertekende of gemanipuleerde images worden geweigerd op de admissielaag in plaats van ontdekt tijdens een post-incident forensisch onderzoek.

Accreditatietraject: een Kubernetes-cluster door ATO of equivalent loodsen

Een exploitatievergunning (ATO) voor een Kubernetes-cluster is niet één document maar een pakket van bewijzen samengesteld om aan te tonen dat het systeem voldoet aan de beveiligingscontroles die zijn gespecificeerd in het toepasselijke kader -- Risk Management Framework (RMF) voor Amerikaanse federale programma's, JSIG voor gezamenlijke inlichtingensystemen, of programmaspecifieke equivalenten voor defensieaanschaffing van geallieerde naties. De autoriserende functionaris beoordeelt dit pakket en neemt een risicoaccordantiebeslissing. Het begrijpen van wat het pakket moet bevatten is essentieel voor het plannen van de accreditatietijdlijn, omdat lacunes die laat in het beoordelingsproces worden ontdekt, de inzet maanden kunnen vertragen.

Het Systeembeveiligingsplan is het centrale document. Voor een Kubernetes-cluster moet het SSP de clusterarchitectuur beschrijven (aantal en plaatsing van control-plane-knooppunten, etcd-topologie, werknemersknooppuntpools, netwerktopologie), de node-hardeningconfiguratie met verwijzingen naar het kube-bench nalevingsrapport, de versleutelingsconfiguratie voor etcd, het RBAC-model (welke serviceaccounts welke machtigingen hebben en waarom), de netwerkbeleidsarchitectuur, de imageprovenance en ondertekeningsketen, en de auditlogdoorsturingsarchitectuur. Elke controle in de toepasselijke basislijn is ofwel vervuld (met een verwijzing naar het bewijs), niet van toepassing (met een rechtvaardiging), of open (met een compenserende controle of POA&M-vermelding).

Continue monitoring is voor de meeste ATO's een voorwaarde in plaats van een eenmalige poort. Het cluster moet worden ingeschreven in een configuratiebeheersysteem dat afwijking van de geharde basislijn detecteert, een kwetsbaarheidsbeheerproces dat CVE's in geïmplementeerde images en knooppunt-OS-pakketten bijhoudt aan de hand van herstel-SLA's, en een logreviewproces dat auditgebeurtenissen bewaakt op anomalieën. Geautomatiseerde tooling -- kube-bench gepland als een Kubernetes CronJob, images die elke nacht opnieuw worden gescand, SIEM-waarschuwingsregels voor verdachte API-serverpatronen -- produceert het bewijs voor continue monitoring zonder handmatige inspanning voor elke reviewcyclus. Programma's die deze automatisering bouwen voor de eerste ATO-indiening staan er veel beter voor bij heraccreditatie dan programma's die continue monitoring behandelen als een nagedachte na autorisatie.