Kubernetes für militärische Workloads: Orchestrierung klassifizierter containerisierter Anwendungen

Container-Orchestrierung hat sich zum dominanten Deployment-Muster für moderne Verteidigungssoftware entwickelt, doch die operativen Sicherheitsanforderungen klassifizierter Umgebungen stellen Anforderungen, die Standard-Kubernetes-Konfigurationen nicht standardmäßig erfüllen. Ein mit kubeadm bootstrappter Cluster setzt unauthentifizierte Kubelet-APIs frei, speichert Secrets im Klartext in etcd, wendet keine Netzwerkrichtlinien zwischen Pods an und erzeugt Audit-Logs, die weder weitergeleitet noch vor Manipulation geschützt sind. Jeder dieser Standardzustände ist ein Befund in jeder ernsthaften Sicherheitsprüfung. Dieser Artikel behandelt, was es bedeutet, Kubernetes in einer klassifizierten Umgebung korrekt zu betreiben: von der Node-Härtung gegenüber CIS- und STIG-Baselines über HSM-gestütztes Secrets-Management, Netzwerk-Mikrosegmentierung, Audit-Log-Architektur, Image-Supply-Chain-Kontrollen bis hin zum Dokumentationsweg zu einer Betriebsgenehmigung (Authority to Operate).

Warum Container-Orchestrierung für das moderne Deployment von Verteidigungssoftware entscheidend ist

Verteidigungssoftware wurde historisch als monolithische Anwendungen auf dedizierten physischen Servern bereitgestellt, wobei jedes System-Upgrade eine manuelle Koordination über mehrere Sicherheitsdomänen hinweg und umfangreiche erneute Tests erforderte, bevor eine Änderung eine Einsatzumgebung erreichte. Container-Orchestrierung kehrt dieses Modell um: Anwendungen werden als unveränderliche Images verpackt, Infrastruktur wird als Code deklariert, und der Orchestrator verwaltet Scheduling, Integritätsprüfung und Rolling Updates über eine Flotte von Nodes. Für Programme, die Fähigkeits-Updates innerhalb von Wochen statt Jahren an Operatoren ausliefern müssen, ist dieser Wandel keine Option.

Kubernetes bietet zusätzliche Vorteile, die für klassifizierte Workloads besonders relevant sind. Die Ressourcenisolation auf Namespace-Ebene ermöglicht es mehreren Anwendungen auf derselben Klassifizierungsstufe, Node-Infrastruktur gemeinsam zu nutzen, ohne sich gegenseitig bei CPU-, Speicher- oder Netzwerkressourcen zu beeinträchtigen. Ressourcen-Quoten verhindern, dass ein fehlfunktionierender Workload die gesamte Cluster-Kapazität verbraucht. Pod Disruption Budgets erzwingen Verfügbarkeitsanforderungen während Wartungsfenstern. Diese Kontrollen entsprechen direkt den Zuverlässigkeits- und Isolationsanforderungen, die bevollmächtigte Beamte in einem System-Sicherheitsplan dokumentiert sehen möchten.

Die Herausforderung besteht darin, dass das Kubernetes-Projekt für internetorientierte kommerzielle Cloud-Umgebungen konzipiert ist und seine Standardkonfiguration dieses Erbe widerspiegelt. Verteidigungsprogramme, die Kubernetes einsetzen, müssen die Standardkonfiguration als Ausgangspunkt für das Hardening betrachten, nicht als akzeptable Baseline. Die Lücke zwischen einem Standard-Cluster und einem akkreditierungsfähigen Cluster ist erheblich, aber sie ist von DISA und dem Center for Internet Security gut dokumentiert und durch gezielte Konfigurationsarbeit schließbar.

Node-Hardening: CIS-Benchmarks und STIG-Compliance für Kubernetes-Worker-Nodes

Das Node-Hardening beginnt auf der Betriebssystemebene, bevor eine einzige Kubernetes-Komponente installiert wird. Worker-Nodes sollten aus einem STIG-gehärteten oder CIS Level 2 Basis-Image aufgebaut werden -- Red Hat Enterprise Linux CoreOS (RHCOS) für OpenShift-basierte Cluster oder ein gehärtetes Ubuntu- oder Rocky-Linux-Build für Upstream-Kubernetes. Die Basis-OS-Konfiguration umfasst Dateisystem-Partitionierung (separate /tmp-, /var-, /var/log-Einhängepunkte), Kernel-Parameter-Härtung (Deaktivierung der IP-Weiterleitung außer wo vom CNI benötigt, Aktivierung von Syncookies, Deaktivierung von IP-Source-Routing), obligatorische Zugriffssteuerung (SELinux im Enforcing-Modus oder AppArmor-Profile) sowie das Entfernen unnötiger Pakete und Dienste.

Auf der Kubernetes-Ebene konvergieren das DISA STIG für Kubernetes und der CIS Kubernetes Benchmark Level 2 auf einen Kernsatz von Kubelet-Konfigurationsanforderungen. Der Read-Only-Port des Kubelets muss deaktiviert werden (--read-only-port=0). Die anonyme Authentifizierung muss deaktiviert werden (--anonymous-auth=false). Der Autorisierungsmodus muss auf Webhook gesetzt werden, sodass alle Autorisierungsentscheidungen an die RBAC-Engine des API-Servers delegiert werden, anstatt knoteninternen Entscheidungen zu vertrauen. Die Zertifikatsrotation muss aktiviert sein, damit Kubelet-Client-Zertifikate automatisch vor Ablauf erneuert werden. Die Container-Runtime -- containerd oder CRI-O -- muss mit einem Standard-Seccomp-Profil (RuntimeDefault) konfiguriert werden, das auf alle Pods angewendet wird, sofern diese kein permissiveres oder benutzerdefiniertes Profil explizit benötigen.

Die Ausführung von kube-bench, dem Open-Source-CIS-Benchmark-Prüfer, gegen einen konfigurierten Cluster erzeugt einen strukturierten Compliance-Bericht im XCCDF-Format. Dieser Bericht ist in den meisten Akkreditierungspaketen eine Pflichtanlage. Category-I-(hochschwere) Befunde müssen vor der Einreichung behoben werden; Category-II-Befunde sollten behoben oder mit kompensierenden Maßnahmen dokumentiert werden. Automatisierte Behebungs-Playbooks -- Ansible oder ähnliches -- die die Benchmark-Kontrollen reproduzierbar auf allen Nodes anwenden, sind gegenüber manueller Konfiguration stark bevorzugt, da sie sowohl den Konfigurationsdrift reduzieren als auch prüfbare Änderungsaufzeichnungen erstellen.

Durchsetzung von Netzwerkrichtlinien: Mikrosegmentierung zwischen klassifizierten Workloads

Standardmäßig können alle Pods in einem Kubernetes-Cluster mit allen anderen Pods kommunizieren, unabhängig vom Namespace. Dieses flache Netzwerkmodell ist für Entwicklungsumgebungen geeignet, aber für klassifizierte Workloads unzulässig, wo das Prinzip des minimalen Rechtezugriffs auf den Netzwerkverkehr genauso angewendet werden muss wie auf RBAC-Berechtigungen. Die Durchsetzung der Netzwerksegmentierung erfordert zwei Dinge: ein CNI-Plugin, das die Kubernetes-NetworkPolicy-Spezifikation implementiert, und eine Reihe von NetworkPolicy-Objekten, die die erlaubten Kommunikationspfade definieren.

Das grundlegende Hardening-Muster ist eine Default-Deny-All-Richtlinie, die beim Cluster-Bootstrap auf jeden Namespace angewendet wird. Diese Richtlinie verweigert den gesamten Ingress- und Egress-Verkehr, sofern keine explizite Allow-Regel ihn erlaubt. Explizite Allow-Regeln werden dann für jeden erforderlichen Verkehrspfad hinzugefügt: DNS-Auflösung (TCP und UDP Port 53 zu CoreDNS in kube-system), Health-Check-Verkehr vom Kubelet zu Anwendungscontainern sowie anwendungsspezifische Service-zu-Service-Kommunikation. Jede Allow-Regel sollte so eng wie möglich gefasst werden -- durch Pod-Label-Selector, Namespace-Label-Selector und Port -- anstatt breite CIDR-Bereiche zu verwenden, die eine Prüfung bestehen, aber keine laterale Bewegung tatsächlich einschränken.

Für Workloads, die auf unterschiedlichen Klassifizierungsstufen auf gemeinsamer Infrastruktur koexistieren müssen, ist eine rein label-basierte NetworkPolicy unzureichend. Das CNI-Plugin erzwingt Richtlinien in der Netfilter-Schicht des Linux-Kernels, und ein ausreichend privilegierter kompromittierter Container kann Netfilter umgehen. Verteidigungsprogramme, die Workloads auf mehreren Sensibilitätsstufen in einem einzigen Cluster hosten, sollten jede Sensibilitätsstufe in einem dedizierten Node-Pool mit dedizierten Netzwerkschnittstellen oder VLANs platzieren und domänenübergreifende Verkehrskontrollen auf Hardware- oder Hypervisor-Ebene erzwingen. Verteidigungscloud-Verbindungsarchitektur bietet die physische und logische Trennung, die richtlinienbasierte Kontrollen auf gemeinsamer Kernel-Infrastruktur nicht garantieren können.

Secrets-Management: Kubernetes mit HSM-gestützten Schlüsselspeichern integrieren

Kubernetes-Secrets werden standardmäßig in etcd als base64-kodierte Werte ohne Verschlüsselung gespeichert. Jeder Benutzer oder Prozess mit Lesezugriff auf etcd -- oder mit ausreichenden RBAC-Berechtigungen zum Aufruf von kubectl get secret -- kann den Klartextwert abrufen. Für klassifizierte Umgebungen ist dies keine Konfigurationslücke, sondern ein grundlegendes Architekturproblem, das gelöst werden muss, bevor sensible Daten im Cluster gespeichert werden. Die Lösung ist die etcd-Verschlüsselung im Ruhezustand mithilfe eines KMS-Providers, der die Schlüsselverwaltung an einen HSM-gestützten Schlüsselspeicher delegiert.

Die kube-apiserver-EncryptionConfiguration-Ressource gibt eine Liste von Verschlüsselungs-Providern für jeden Ressourcentyp an. Beim KMS-Provider zeigt die Konfiguration auf einen Unix-Socket, an dem ein KMS-Plugin-Prozess lauscht. Das Plugin übersetzt das Kubernetes-KMS-gRPC-Protokoll in Aufrufe an das HSM oder den Schlüsselverwaltungsdienst -- typischerweise über PKCS#11 für ein netzwerkgebundenes HSM oder über die Schlüsselverwaltungs-API eines militärischen Cloud-KMS. Wenn der API-Server ein Secret in etcd schreibt, ruft er das KMS-Plugin auf, um den Datenverschlüsselungsschlüssel (DEK) unter dem im HSM gehaltenen Schlüssel-Verschlüsselungsschlüssel (KEK) einzuschließen. Nur der eingeschlossene DEK wird zusammen mit dem verschlüsselten Text in etcd gespeichert. Die Entschlüsselung erfordert einen Round-Trip zum HSM. Das HSM muss nach FIPS 140-2 Level 3 für Workloads auf GEHEIM-Ebene validiert sein; Level 2 ist im Allgemeinen nur für SENSIBLES, aber NICHT KLASSIFIZIERTES Material akzeptabel.

Audit-Protokollierung: API-Server-Ereignisse für Compliance und Forensik erfassen

Der Kubernetes-API-Server erzeugt ein Audit-Log jeder von ihm verarbeiteten Anfrage: wer die Anfrage gestellt hat, welches Verb und welche Ressource betroffen war, in welchem Namespace, ob die Anfrage erfolgreich war und -- abhängig von der konfigurierten Audit-Ebene -- den vollständigen Anfrage- und Antwort-Body. Dieses Log ist die maßgebliche Aufzeichnung zur Beantwortung der Frage "Wer hat was wann in diesem Cluster getan." Für klassifizierte Umgebungen ist eine umfassende Audit-Protokollierung nicht optional; sie ist eine spezifische Kontrollanforderung in RMF, JSIG und entsprechenden Rahmenwerken, und das Fehlen angemessener Audit-Logs ist typischerweise ein showstopping-Befund bei einer Akkreditierungsprüfung.

Die Audit-Richtlinie ist eine YAML-Datei, die beim Start an den kube-apiserver übergeben wird und Ressourcentypen sowie Verben Audit-Ebenen zuordnet. Die vier Ebenen sind None (keine Protokollierung), Metadata (Benutzer, Verb, Ressource, Status -- kein Body), Request (fügt den Anfrage-Body hinzu) und RequestResponse (fügt sowohl Anfrage- als auch Antwort-Body hinzu). Eine compliance-gerechte Richtlinie erfasst RequestResponse für Secrets, ConfigMaps, Roles, RoleBindings, ClusterRoles, ClusterRoleBindings und ServiceAccounts -- die Ressourcen, deren Änderung auf Privilege Escalation oder Credential-Diebstahl hinweisen könnte. Pod-Exec- und -Attach-Aufrufe müssen ebenfalls auf RequestResponse-Ebene erfasst werden, da dies die primären Vektoren für interaktive laterale Bewegung in einem kompromittierten Cluster sind. Alle anderen Ressourcen können auf Metadata-Ebene protokolliert werden, was ein vollständiges Zugriffsprotokoll erzeugt, ohne den Speicher-Overhead des Erfassens jedes Anwendungs-Payloads zu verursachen.

Audit-Logs, die nur auf dem Control-Plane-Node gespeichert werden, sind für einen kompromittierten Cluster-Administrator manipulierbar. Eine militärische Audit-Architektur leitet Logs an ein externes Ziel weiter, auf das der Cluster selbst nicht schreiben oder löschen kann: ein SIEM (Security Information and Event Management-System), einen Append-Only-S3-kompatiblen Objektspeicher mit Object-Lock-Aufbewahrung oder einen dedizierten Syslog-Forwarder zu einer luftgetrennten Log-Aggregations-Infrastruktur. Der Log-Shipper -- ein Fluentd- oder Fluent-Bit-DaemonSet auf Control-Plane-Nodes -- muss mit einem Kubernetes-Service-Account laufen, der keine Berechtigungen für die protokollierten Cluster-Objekte hat, damit ein kompromittierter Shipper seine eigenen Spuren nicht verwischen kann, indem er die Audit-Richtlinie ändert oder Log-Dateien löscht.

Image-Scanning und Supply-Chain-Sicherheit in klassifizierten Container-Registrys

Jedes in einen klassifizierten Cluster deployierte Container-Image ist eine potenzielle Supply-Chain-Angriffsfläche. Ein ohne Inspektion aus einer öffentlichen Registry gezogenes Image kann bekannte anfällige Bibliotheksversionen, eingebettete Anmeldeinformationen oder schädlichen Code enthalten, der während der Build-Pipeline eingeführt wurde. Verteidigungsprogramme müssen eine private Container-Registry betreiben, die vom öffentlichen Internet isoliert ist, authentifizierten Zugriff erfordert und Schwachstellen-Scanning sowie Image-Signierung erzwingt, bevor ein Image in den Cluster zugelassen wird.

Image-Schwachstellen-Scanning-Tools wie Trivy oder Grype analysieren jede Image-Schicht gegen die OSV-Beratungsdatenbank und Anbieter-Sicherheitsbulletins und erstellen eine Liste von CVEs mit Schweregradpunktzahlen und betroffenen Paketversionen. In einer klassifizierten CI-Pipeline läuft das Scanning als Teil des Image-Build-Prozesses; Images, die kritische oder hochschwere CVEs enthalten, werden vom Push in die Produktions-Registry blockiert, bis die Schwachstellen behoben oder formal als Risiken akzeptiert wurden. Die Scan-Ergebnisse werden zusammen mit dem Image in den Registry-Metadaten gespeichert und im Akkreditierungsnachweis-Paket als Beweis referenziert, dass das Software-Inventar bekannt und überprüft ist.

Image-Signierung fügt eine kryptografische Bestätigung hinzu, dass ein bestimmter Image-Digest von einer bestimmten Build-Pipeline erzeugt wurde und seit der Signierung nicht verändert wurde. Das cosign-Tool des Sigstore-Projekts unterstützt die Signierung mit einem in einem HSM oder KMS gespeicherten Schlüssel und erzeugt eine Signatur-Attestierung, die zusammen mit dem Image in der Registry gespeichert wird. Der Kubernetes-Admission-Webhook -- mithilfe einer Policy-Engine wie Kyverno oder OPA Gatekeeper -- überprüft die Signatur, bevor ein Pod geplant wird. Diese Lieferkette vom Build bis zum Deployment entspricht genau den Anforderungen von Supply-Chain-Sicherheits-Rahmenwerken: Jeder im Cluster laufende Workload ist auf ein spezifisches signiertes Build-Artefakt zurückführbar, und unsignierte oder manipulierte Images werden auf der Admission-Ebene abgelehnt, anstatt erst bei einer Post-Incident-forensischen Prüfung entdeckt zu werden.

Akkreditierungsweg: Einen Kubernetes-Cluster durch eine Betriebsgenehmigung oder gleichwertige Zulassung führen

Eine Betriebsgenehmigung (Authority to Operate) für einen Kubernetes-Cluster ist kein einzelnes Dokument, sondern ein Nachweispaket, das zeigt, dass das System die im anwendbaren Rahmenwerk spezifizierten Sicherheitskontrollen erfüllt -- Risk Management Framework (RMF) für US-Bundesbehörden, JSIG für gemeinsame Geheimdienstsysteme oder programmspezifische Äquivalente für die Verteidigungsbeschaffung alliierter Nationen. Der bevollmächtigte Beamte prüft dieses Paket und trifft eine Risikoakzeptanzentscheidung. Das Verständnis, was das Paket enthalten muss, ist für die Planung des Akkreditierungszeitplans unerlässlich, da spät im Prüfungsprozess entdeckte Lücken die Inbetriebnahme um Monate verzögern können.

Der System-Sicherheitsplan ist das zentrale Dokument. Für einen Kubernetes-Cluster muss der SSP die Cluster-Architektur beschreiben (Anzahl und Platzierung der Control-Plane-Nodes, etcd-Topologie, Worker-Node-Pools, Netzwerktopologie), die Node-Hardening-Konfiguration mit Verweisen auf den kube-bench-Compliance-Bericht, die Verschlüsselungskonfiguration für etcd, das RBAC-Modell (welche Service-Accounts welche Berechtigungen haben und warum), die Netzwerkrichtlinien-Architektur, die Image-Herkunft und die Signierungskette sowie die Audit-Log-Weiterleitungs-Architektur. Jede Kontrolle in der anwendbaren Baseline ist entweder erfüllt (mit einem Verweis auf den Nachweis), nicht anwendbar (mit einer Begründung) oder offen (mit einer kompensierenden Maßnahme oder einem POA&M-Eintrag).

Die kontinuierliche Überwachung ist bei den meisten Betriebsgenehmigungen eine Bedingung und kein einmaliger Schritt. Der Cluster muss in ein Konfigurationsmanagementsystem eingebunden werden, das Abweichungen von der gehärteten Baseline erkennt, einen Schwachstellenmanagementprozess, der CVEs in deployten Images und Node-OS-Paketen gegenüber Behebungs-SLAs verfolgt, sowie einen Log-Prüfungsprozess, der Audit-Ereignisse auf Anomalien überwacht. Automatisierte Werkzeuge -- kube-bench als Kubernetes-CronJob geplant, Image-Rescanning im nächtlichen Zeitplan, SIEM-Alarmierungsregeln für verdächtige API-Server-Muster -- erzeugen den Nachweis der kontinuierlichen Überwachung, ohne dass für jeden Prüfungszyklus manuelle Arbeit erforderlich ist. Programme, die diese Automatisierung vor der ersten ATO-Einreichung aufbauen, sind bei der Wiederautorisierung in einer weit stärkeren Position als solche, die die kontinuierliche Überwachung als nachgelagerte Aufgabe nach der Genehmigung betrachten.