Kubernetes is het standaard orkestratieplatform geworden voor cloudworkloads in de defensiesector — van gecontaineriseerde C2-systemen en sensordata-pipelines tot AI-inferentiediensten die op de tactische rand draaien. Deze adoptie brengt een beveiligingsprobleem met zich mee dat enterprise Kubernetes-hardingsgidsen niet aanpakken: het bedreigingsmodel voor een militaire workload verschilt fundamenteel van het bedreigingsmodel voor een commerciële SaaS-applicatie. De tegenstander beschikt over middelen op staatsniveau, de insider-bedreiging heeft een veiligheidsmachtiging, de toeleveringsketen is een legitieme aanvalsvector, en de gevolgen van een containerontsnapping of data-exfiltratie zijn het verlies van geclassificeerde gegevens in plaats van een PCI-boete. Standaard enterprise-harding is noodzakelijk maar niet voldoende.

Deze gids behandelt de volledige stack van cloudbeveiliging voor militaire workloads in Kubernetes: het defensiespecifieke bedreigingsmodel, pod-isolatie, netwerksegmentatie, secretbeheer, RBAC-harding, integriteit van de image-toeleveringsketen, detectie van runtime-anomalieën en automatisering van continue compliance.

1. Kubernetes-bedreigingsmodel voor defensie

Vijandige insider met legitieme toegang. Controlemechanismen moeten ervan uitgaan dat een aanvaller legitiem kan authenticeren en moeten steunen op het principe van minimale rechten, gedragsmonitoring en manipulatiebestendige auditsporen in plaats van alleen op perimetervAuthentisering.

Compromittering van de toeleveringsketen. Controlemechanismen moeten elke containerimage behandelen als potentieel gecompromitteerd totdat een geverifieerde cryptografische attestatie het tegendeel bewijst.

Netwerkgebaseerde laterale beweging. Defensieclusters kunnen het Kubernetes-standaard van onbeperkte pod-naar-pod-communicatie niet tolereren. Netwerkcontroles moeten altijd uitgaan van compromittering van ten minste één pod.

Containerontsnapping. Voor geclassificeerde workloads is een containerontsnapping gelijkwaardig aan directe toegang tot de host en potentieel tot elke andere workload op dat knooppunt.

2. Pod-beveiliging: PodSecurityAdmission en containerharding

Voor militaire workloads is het PSA restricted-profiel de basisvereiste voor alle applicatienaamruimten. Het dwingt af: geen geprivilegieerde containers, geen host-naamruimte delen, geen root-gebruiker, alleen-lezen root-bestandssysteem, alle capabilities verwijderd en een RuntimeDefault seccomp-profiel.

3. Netwerkbeleid: zero-trust pod-naar-pod communicatie

Elke naamruimte vereist een standaard-weiger-NetworkPolicy bij aanmaak die zowel inkomend als uitgaand verkeer dekt. Calico en Cilium zijn de twee CNI-plugins die geschikt zijn voor defensiegebruik. Voor defensieclusters met luchtgat is het blokkeren van uitgaand verkeer niet onderhandelbaar. De eBPF-handhaving van Cilium verwerpt niet-toegestane pakketten in de netwerkstack van de kernel.

4. Secretbeheer: Vault, Sealed Secrets en HSM-ondersteunde KMS

HashiCorp Vault met de vault-agent sidecar-injector is de standaard secretbeheeroplossing voor defensie-Kubernetes. Secrets worden geschreven naar een in-memory tmpfs-volume — nooit naar schijf en nooit als omgevingsvariabelen. Sealed Secrets maakt GitOps-workflows mogelijk door secretmanifests te versleutelen voor veilige Git-opslag. Voor de hoogste classificatieniveaus moet de KMS die Vault's auto-unseal ondersteunt een FIPS 140-2 Level 3 HSM zijn.

5. RBAC-harding: minimale rechten, naamruimte-isolatie, auditlogboekregistratie

Toegewijde ServiceAccounts per workload, token-automatisch koppelen standaard uitgeschakeld, geen ClusterRoleBindings voor applicatieworkloads. API-server auditlogs worden in realtime verzonden naar een externe, alleen-toevoegen logopslag buiten het explosieradius van een gecompromitteerde workloadcluster.

6. Image-toeleveringsketen: Cosign-ondertekening, admission webhooks, privéregister

Alle images zijn ondertekend met Cosign met een KMS- of HSM-ondersteunde sleutel. Kyverno dwingt handtekeningverificatie af bij toelating. Productienaamruimten halen alleen uit een intern privéregister; geen toegang tot publieke registers is toegestaan.

7. Runtime-beveiliging: Falco, eBPF-monitoring, gVisor voor niet-vertrouwde workloads

Falco biedt realtime kernel-syscall-monitoring via eBPF met MITRE ATT&CK-gekoppelde regels en aangepaste defensieregels. Waarschuwingen worden in realtime naar de SIEM gestuurd. gVisor sandboxt niet-vertrouwde workloads; standaard containers met Falco/seccomp verwerken latentiegevoelige missie-workloads.

8. Compliance-automatisering: kube-bench, STIG-controles, continue rapportage

kube-bench voert CIS Benchmark-controles continu uit, met resultaten die zijn gekoppeld aan DISA Kubernetes STIG-controle-ID's voor geautomatiseerd compliancebewijs. Mislukte controles blokkeren CI/CD-pipeline-promoties. Trivy/Grype, Checkov en Polaris completeren de compliancestack.

Kerninzicht: De gevaarlijkste storingsvorm is drift — een cluster dat de hardingsbeoordeling bij implementatie doorstond maar stilzwijgend verslechterde over zes maanden. Behandel de compliancehouding als een realtimemetric. Zie de uitgebreide gids voor defensiecyberbeveiliging voor het omringende kader.

Cloudbeveiliging voor militaire workloads in Kubernetes is een gelaagde set controlemechanismen — pod-beveiliging, netwerkbeleid, Vault, RBAC-harding, image-ondertekening, Falco en continue compliance-scanning — elk gericht op een afzonderlijke bedreigingsvector, elk continu onderhouden naarmate het cluster en zijn workloads evolueren.