Kubernetes-hardening voor defensie-workloads: CIS-benchmarks en NSA-richtlijnen

Kubernetes is uitgegroeid tot het standaard deploymentplatform voor gecontaineriseerde applicaties in defensie, van DoD Platform One tot nationale defensie-cloudprogramma's in NATO-lidstaten. De adoptie ervan in defensie-omgevingen wordt aangedreven door dezelfde operationele voordelen die ook de commerciële adoptie stimuleerden: consistente deployment over verschillende omgevingen, geautomatiseerde schaling, zelfherstellende workloads en declaratief infrastructuurbeheer. Maar een standaard Kubernetes-installatie is ontworpen voor gebruiksgemak, niet voor beveiliging — en het beveiligingsverschil tussen een standaardinstallatie en een geharde, defensie-waardige deployment is aanzienlijk.

NSA en CISA publiceerden de Kubernetes Hardening Guide (v1.2, augustus 2022) specifiek om dit gat te dichten. De gids behandelt het hardenen van de control plane, netwerkbeveiliging, podbeveiliging, audit logging en authenticatie en autorisatie — en biedt een praktisch startpunt voor Kubernetes-deployments in defensie. De CIS Kubernetes Benchmark levert een aanvullende, meer granulaire set van gescoorde configuratiecontroles. Samen definiëren deze twee documenten wat "geharden" betekent voor Kubernetes in een defensiecontext.

NSA/CISA Kubernetes Hardening Guide: belangrijkste aanbevelingen

De NSA/CISA-gids ordent de aanbevelingen in zes categorieën. De operationeel meest significante voor defensie zijn:

Kubernetes-podbeveiliging. Pods moeten gebruikmaken van non-root containers, read-only root-bestandssystemen en hun capabilities teruggebracht hebben tot het strikt noodzakelijke minimum. Geprivilegieerde containers — die volledige toegang hebben tot het hostsysteem — mogen niet worden toegestaan in productie-workloads.

Netwerkscheiding en -hardening. Al het verkeer tussen services moet worden versleuteld met TLS (service mesh met mTLS). Network Policies moeten pod-naar-pod-communicatie beperken tot expliciet toegestane paden. De Kubernetes API-server mag niet rechtstreeks toegankelijk zijn vanaf het internet of vanuit niet-vertrouwde netwerksegmenten.

Authenticatie en autorisatie. De API-server mag geen anonieme authenticatie of onveilige poorten inschakelen. Role-Based Access Control (RBAC) moet zijn ingeschakeld en geconfigureerd volgens least-privilege-principes. Service-accounttokens mogen niet automatisch worden gemount op pods die geen toegang tot de API-server nodig hebben.

Audit logging. Audit logging van de API-server moet zijn ingeschakeld met een policy die ten minste create-, update-, delete- en get-operaties op gevoelige resourcetypen vastlegt. Auditlogs moeten worden doorgestuurd naar een centraal SIEM- of logbeheersysteem waar ze niet door clusterbeheerders kunnen worden gewijzigd.

Upgradefrequentie. Kubernetes-versies ontvangen ongeveer 14 maanden na release beveiligingspatches. Het draaien van niet-ondersteunde Kubernetes-versies vormt een aanzienlijk beveiligingsrisico dat onaanvaardbaar is in defensie-deployments.

Pod Security Standards: het Restricted-profiel

Kubernetes Pod Security Standards (PSS) definiëren drie policyprofielen — Privileged, Baseline en Restricted — die toenemende niveaus van beperking op de podconfiguratie vertegenwoordigen. Het Restricted-profiel is de juiste baseline voor defensie-workloads: het dwingt de meest beveiligingsrelevante beperkingen op de podconfiguratie af.

Het Restricted-profiel verbiedt: geprivilegieerde containers (containers met de vlag privileged op true), containers die als root draaien (afgedwongen via runAsNonRoot: true), containers die toegang krijgen tot het hostnetwerk (hostNetwork: false), containers die toegang krijgen tot host-PID's of -IPC's (hostPID: false, hostIPC: false), containers die hostpaden als volumes mounten, en containers die Linux-capabilities toevoegen buiten een gedefinieerde allowlist.

Het implementeren van het Restricted-profiel in een bestaande Kubernetes-omgeving vereist vaak aanpassingen aan applicaties: applicaties die zijn geschreven in de veronderstelling van root-toegang, schrijftoegang tot het bestandssysteem of toegang tot het hostnetwerk moeten worden herzien om binnen het Restricted-profiel te functioneren. Voor nieuwe defensie-applicatieontwikkeling zou naleving van het Restricted-profiel vanaf het begin een ontwerpvereiste moeten zijn — het achteraf inbouwen na deployment is aanzienlijk duurder.

Pod Security Standards worden afgedwongen via de ingebouwde PodSecurity-admission controller (beschikbaar sinds Kubernetes 1.25, ter vervanging van de afgeschafte PodSecurityPolicy). De afdwingmodi zijn Enforce (pods die de policy overtreden worden geweigerd), Audit (overtredingen worden gelogd maar pods worden toegestaan) en Warn (overtredingen genereren API-waarschuwingen maar pods worden toegestaan). Defensie-deployments zouden de Enforce-modus moeten gebruiken voor het Restricted-profiel in alle productie-namespaces.

Network Policies: microsegmentatie met Calico of Cilium

Kubernetes Network Policies bepalen welke pods met welke andere pods kunnen communiceren op IP/poort-niveau. Zonder Network Policies kunnen alle pods in een cluster met alle andere pods communiceren — een platte netwerktopologie die architectonisch onverenigbaar is met zero-trust-principes. Network Policies implementeren de microsegmentatielaag op het niveau van het containernetwerk.

Calico is de meest gebruikte implementatie van Kubernetes-netwerkpolicy en ondersteunt zowel standaard Kubernetes NetworkPolicy-resources als Calico-specifieke GlobalNetworkPolicy- en NetworkPolicy-resources met aanvullende mogelijkheden. Calico kan in verschillende modi worden geïmplementeerd (BGP-routing, VXLAN-overlay of eBPF-dataplane) en integreert met externe firewalls via BGP-route-advertentie. Voor air-gapped defensie-omgevingen maken Calico's on-premises deploymentmodel en het ontbreken van afhankelijkheden van een cloud-control plane het operationeel geschikt.

Cilium gebruikt eBPF (Extended Berkeley Packet Filter) voor het afdwingen van netwerkpolicy in de Linux-kernel, wat hogere prestaties levert dan op iptables gebaseerde oplossingen en Layer 7- (applicatielaag) netwerkpolicy's ondersteunt — bijvoorbeeld het toestaan van HTTP GET-verzoeken maar het blokkeren van POST-verzoeken op een specifiek API-pad. Cilium's Hubble-observability-component biedt gedetailleerd inzicht in netwerkstromen en ondersteunt zowel security monitoring als troubleshooting. Cilium's integratie met SPIFFE/SPIRE voor workload-identiteit biedt een weg naar mTLS-gebaseerde microsegmentatie zonder een volledige service mesh-deployment.

Het kernprincipe voor het ontwerp van Network Policy in defensie is default-deny: nieuwe namespaces zouden een default-deny NetworkPolicy moeten hebben die alle ingress en egress blokkeert totdat expliciete allow-regels zijn aangemaakt. Dit zorgt ervoor dat nieuwe workloads geïsoleerd zijn totdat hun netwerktoegangsvereisten expliciet zijn gedocumenteerd en goedgekeurd, in plaats van de permissieve standaardinstelling over te erven.

Admission controllers: policy-as-code met OPA/Gatekeeper en Kyverno

Admission controllers zijn plug-ins die API-serververzoeken onderscheppen voordat ze naar etcd worden gepersisteerd, waardoor policy's op het niveau van de cluster-API kunnen worden afgedwongen. OPA/Gatekeeper en Kyverno zijn de twee dominante policy-as-code-frameworks voor Kubernetes-admissioncontrole.

OPA/Gatekeeper gebruikt de OPA-policy-engine (Open Policy Agent) met de policytaal Rego. Gatekeeper registreert zich als een ValidatingAdmissionWebhook die de OPA-policy-engine aanroept voor elk relevant API-verzoek. Constraint Templates definiëren de policystructuur; Constraints instantiëren de template voor specifieke resources. Het OPA/Gatekeeper-ecosysteem beschikt over een grote bibliotheek van kant-en-klare policy's die veelvoorkomende beveiligingsvereisten afdekken, en op maat gemaakte policy's kunnen in Rego worden geschreven voor organisatiespecifieke vereisten.

Kyverno gebruikt Kubernetes-native YAML om policy's uit te drukken, waardoor het toegankelijker is voor teams die bekend zijn met Kubernetes-resourcedefinities maar zich niet comfortabel voelen bij Rego. Kyverno ondersteunt zowel validatie (het blokkeren van niet-conforme resources) als mutatie (het automatisch toevoegen van vereiste labels of security-context-velden aan resources die deze missen). Kyverno's mutating admission-webhook-mogelijkheid is bijzonder nuttig voor het automatisch toepassen van beveiligingsstandaarden, waardoor de last voor applicatieontwikkelaars wordt verminderd.

Voor defensie-deployments zouden admissioncontrole-policy's ten minste het volgende moeten afdwingen: image-herkomst (images moeten afkomstig zijn uit goedgekeurde registries), image-signing (images moeten geldige cosign-handtekeningen hebben), security-context-vereisten (non-root, geen privileged, geen host-namespaces), vereiste labels (voor asset tracking en compliance-rapportage) en resource-limieten (alle containers moeten gedefinieerde CPU- en geheugenlimieten hebben).

Runtime security: Falco, seccomp en AppArmor

Falco (CNCF-graduated) is het standaard runtime-securitytool voor Kubernetes: het bewaakt kernel-systeemaanroepen in realtime en genereert waarschuwingen wanneer gedrag overeenkomt met verdachte patronen. Falco-regels dekken procesuitvoering (onverwachte uitvoerbare bestanden die binnen containers draaien), bestandstoegang (schrijfacties naar systeemmappen, het lezen van gevoelige bestanden), netwerkactiviteit (onverwachte uitgaande verbindingen vanuit containers) en Kubernetes API-activiteit (ongeautoriseerde API-aanroepen, pogingen tot credentialdiefstal). Falco integreert met SIEM-systemen via syslog- of Webhook-output, waardoor container-runtime-events worden aangeleverd aan de bredere security-monitoringinfrastructuur.

seccomp (secure computing mode)-profielen beperken de systeemaanroepen die beschikbaar zijn voor containerprocessen. Een proces in een container die met een seccomp-profiel draait, kan alleen de systeemaanroepen doen die expliciet door dat profiel zijn toegestaan — alle andere worden geblokkeerd. Kubernetes biedt een standaard seccomp-profiel (RuntimeDefault) dat de gevaarlijkste systeemaanroepen blokkeert terwijl normale applicatiewerking mogelijk blijft. Defensie-workloads zouden ten minste het RuntimeDefault-profiel moeten gebruiken; workloads met een hoog risico zouden op maat gemaakte profielen moeten gebruiken die nog restrictiever zijn.

AppArmor (op Linux-distributies die het ondersteunen) biedt een laag voor Mandatory Access Control die beperkt tot welke bestanden, capabilities en netwerkoperaties elk proces toegang heeft. AppArmor-profielen voor Kubernetes-containers definiëren wat het containerproces mag doen, wat een defense-in-depth-laag toevoegt onder de container-runtime en boven de kernel.