Kubernetes hat sich zur Standard-Orchestrierungsplattform für Cloud-Workloads im Verteidigungsbereich entwickelt — von containerisierten C2-Systemen und Sensordaten-Pipelines bis hin zu KI-Inferenzdiensten am taktischen Rand. Diese Verbreitung bringt ein Sicherheitsproblem mit sich, das Enterprise-Kubernetes-Härtungsleitfäden nicht adressieren: Das Bedrohungsmodell für einen militärischen Workload unterscheidet sich grundlegend vom Bedrohungsmodell einer kommerziellen SaaS-Anwendung. Der Angreifer verfügt über Ressourcen auf Staatsniveau, die Insider-Bedrohung besitzt eine Sicherheitsfreigabe, die Lieferkette ist ein legitimer Angriffsvektor, und die Folgen eines Container-Ausbruchs oder einer Datenexfiltration sind Verlust geheimer Daten statt einer PCI-Geldstrafe. Standard-Enterprise-Härtung ist notwendig, aber nicht ausreichend.

Dieser Leitfaden deckt den vollständigen Stack der Cloud-Sicherheit für militärische Workloads in Kubernetes ab: das verteidigungsspezifische Bedrohungsmodell, Pod-Isolierung, Netzwerksegmentierung, Secrets-Management, RBAC-Härtung, Integrität der Image-Lieferkette, Laufzeit-Anomalieerkennung und Automatisierung der kontinuierlichen Compliance.

1. Kubernetes-Bedrohungsmodell für die Verteidigung

Feindlicher Insider mit legitimem Zugang. In einem Verteidigungsumfeld besitzen Insider Sicherheitsfreigaben und haben autorisierten Zugang. Kontrollmechanismen müssen davon ausgehen, dass ein Angreifer sich legitim authentifizieren kann, und sich auf das Prinzip der minimalen Rechte, Verhaltensüberwachung und manipulationssichere Prüfprotokolle stützen statt allein auf Perimeter-Authentifizierung.

Kompromittierung der Lieferkette. Staatliche Angreifer kompromittieren vorgelagerte Software-Lieferketten — Build-Systeme, Open-Source-Pakete, Container-Basis-Images und CI/CD-Pipelines. Kontrollmechanismen müssen jedes Container-Image als potenziell kompromittiert betrachten, bis eine verifizierte kryptografische Attestierung das Gegenteil beweist.

Netzwerkbasierte seitliche Bewegung. Kubernetes-Cluster erlauben standardmäßig uneingeschränkte Pod-zu-Pod-Kommunikation. Ein Angreifer, der Code-Ausführung innerhalb eines beliebigen Containers erreicht, kann sofort jeden anderen Dienst im Cluster scannen und angreifen. Verteidigungscluster können diese Voreinstellung nicht tolerieren.

Container-Ausbruch. Ein Container-Ausbruch erlaubt es Code, der innerhalb eines Containers läuft, die Container-Grenze zu durchbrechen und mit Host-Kernel- oder Host-Root-Privilegien auszuführen. Für geheime Workloads entspricht ein Container-Ausbruch dem direkten Zugang zum Host und potenziell zu jedem anderen Workload auf diesem Knoten.

2. Pod-Sicherheit: PodSecurityAdmission und Container-Härtung

PSA erzwingt eines von drei Profilen auf Namespace-Ebene: privileged, baseline und restricted. Für militärische Workloads ist das restricted-Profil die Grundanforderung. Markieren Sie jeden Anwendungs-Namespace mit pod-security.kubernetes.io/enforce: restricted. Das restricted-Profil erzwingt: keine privilegierten Container, keine Host-Namespace-Freigabe, keinen Root-Benutzer, schreibgeschütztes Root-Dateisystem, alle Capabilities entfernt und ein seccomp-Profil von RuntimeDefault oder Localhost.

3. Netzwerkrichtlinien: Zero-Trust-Pod-zu-Pod-Kommunikation

Jeder Namespace benötigt eine Standard-Deny-NetworkPolicy, die bei der Erstellung angewendet wird und sowohl eingehenden als auch ausgehenden Datenverkehr abdeckt. Calico und Cilium sind die zwei für den Verteidigungseinsatz geeigneten CNI-Plugins. Für Verteidigungscluster mit Air-Gap ist das Blockieren von ausgehendem Datenverkehr nicht verhandelbar. Die eBPF-Durchsetzung von Cilium verwirft nicht erlaubte Pakete im Kernel-Netzwerkstack, bevor sie die Anwendung erreichen.

4. Secrets-Management: Vault, Sealed Secrets und HSM-gesichertes KMS

HashiCorp Vault mit dem vault-agent-Sidecar-Injektor ist die Standard-Lösung für Secrets-Management in Verteidigungs-Kubernetes. Secrets werden in ein In-Memory-tmpfs-Volume geschrieben — niemals auf Disk und niemals als Umgebungsvariablen. Sealed Secrets ermöglichen GitOps-Workflows durch Verschlüsselung von Secret-Manifests zur sicheren Git-Speicherung. Für die höchsten Klassifizierungsstufen sollte das KMS, das Vaults Auto-Unseal unterstützt, ein FIPS 140-2 Level 3 HSM sein.

5. RBAC-Härtung: minimale Rechte, Namespace-Isolierung, Audit-Protokollierung

Jeder Workload läuft unter einem dedizierten ServiceAccount mit standardmäßig deaktiviertem Token-Auto-Mounting. Keine ClusterRoleBindings für Anwendungs-Workloads. API-Server-Audit-Protokollierung erfasst RequestResponse-Ebene für Secrets, ConfigMaps und RBAC-Objekte, in Echtzeit an einen externen, nur zum Anhängen geeigneten Log-Speicher außerhalb des Explosionsradius eines kompromittierten Workload-Clusters geliefert.

6. Image-Lieferkette: Cosign-Signierung, Admission-Webhooks, privates Registry

Jedes Image trägt eine Cosign-Signatur von einem in KMS oder HSM gespeicherten Schlüssel. Kyverno erzwingt Signaturverifizierung bei der Zulassung und blockiert jeden Pod, dessen Image keine gültige Signatur trägt. Alle Produktions-Images stammen aus einem internen privaten Registry — kein Abruf aus öffentlichen Registries ist in Produktions-Namespaces gestattet.

7. Laufzeitsicherheit: Falco, eBPF-Monitoring, gVisor für nicht vertrauenswürdige Workloads

Falco überwacht Kernel-Syscalls in Echtzeit über eine eBPF-Probe und alarmiert bei in Containern gestarteten Shells, unerwarteten ausgehenden Verbindungen, Schreibvorgängen in sensible Pfade und Privilegien-Eskalationsversuchen. Warnmeldungen werden in Echtzeit an das SIEM gesendet. gVisor wird für nicht vertrauenswürdige Workload-Ebenen eingesetzt; Standard-Container mit Falco und seccomp werden für latenzsensitive Mission-Workloads verwendet.

8. Compliance-Automatisierung: kube-bench, STIG-Prüfungen, kontinuierliches Reporting

kube-bench führt CIS Kubernetes Benchmark-Prüfungen als geplanten Job aus, mit Ergebnissen, die auf DISA Kubernetes STIG-Prüf-IDs für automatisierte Compliance-Nachweise abgebildet werden. Fehlgeschlagene Prüfungen oberhalb eines Schweregradgrenzwerts blockieren CI/CD-Pipeline-Promotionen. Trivy/Grype, Checkov und Polaris vervollständigen den kontinuierlichen Compliance-Stack.

Wichtige Erkenntnis: Der häufigste Fehlermodus bei der Kubernetes-Sicherheit in Verteidigungsumgebungen ist die Lücke zwischen dem, was die Zugangsrichtlinie aussagt, und dem, was nach sechs Monaten operativer Änderungen tatsächlich läuft. Behandeln Sie den Compliance-Status als Echtzeit-Metrik, nicht als jährliches Audit-Artefakt. Sehen Sie den vollständigen Leitfaden zur Verteidigungscybersicherheit für das übergeordnete Kontrollrahmenwerk.

Die Cloud-Sicherheit militärischer Workloads in Kubernetes ist ein mehrschichtiger Satz von Kontrollen — Pod-Sicherheit, Netzwerkrichtlinien, Vault, RBAC-Härtung, Image-Signierung, Falco und kontinuierliches Compliance-Scanning — jede einen anderen Bedrohungsvektor adressierend, jede kontinuierlich gepflegt, während sich der Cluster und seine Workloads weiterentwickeln.