Kubernetes-Hardening für Verteidigungs-Workloads: CIS-Benchmarks und NSA-Richtlinien

Kubernetes hat sich zur Standardbereitstellungsplattform für containerisierte Anwendungen im Verteidigungsbereich entwickelt — von DoD Platform One bis zu nationalen Verteidigungscloud-Programmen in NATO-Mitgliedstaaten. Seine Einführung in Verteidigungsumgebungen wird von denselben betrieblichen Vorteilen angetrieben, die die kommerzielle Einführung vorangetrieben haben: konsistente Bereitstellung in verschiedenen Umgebungen, automatische Skalierung, selbstheilende Workloads und deklaratives Infrastrukturmanagement. Eine Standard-Kubernetes-Installation ist jedoch auf Benutzerfreundlichkeit, nicht auf Sicherheit ausgelegt — und der Sicherheitsunterschied zwischen einer Standardinstallation und einem gehärteten, verteidigungsgerechten Deployment ist erheblich.

NSA und CISA haben den Kubernetes Hardening Guide (v1.2, August 2022) speziell zur Behebung dieser Lücke veröffentlicht. Der Leitfaden behandelt Control-Plane-Härtung, Netzwerksicherheit, Pod-Sicherheit, Audit-Protokollierung sowie Authentifizierung und Autorisierung. Der CIS Kubernetes Benchmark bietet einen ergänzenden, detaillierteren Satz bewerteter Konfigurationsprüfungen. Gemeinsam definieren diese beiden Dokumente, was „gehärtet" für Kubernetes in einem Verteidigungskontext bedeutet.

NSA/CISA Kubernetes Hardening Guide: Wichtigste Empfehlungen

Der NSA/CISA-Leitfaden gliedert Empfehlungen in sechs Kategorien. Die operativ bedeutsamsten für die Verteidigung sind:

Kubernetes Pod-Sicherheit. Pods sollten Container ohne Root-Rechte, schreibgeschützte Root-Dateisysteme verwenden und Capabilities auf das erforderliche Minimum reduziert haben. Privilegierte Container — mit vollem Zugriff auf das Host-System — dürfen in Produktions-Workloads nicht zugelassen werden.

Netzwerkseparierung und -härtung. Der gesamte Inter-Service-Verkehr sollte mit TLS verschlüsselt werden (Service Mesh mit mTLS). Network Policies sollten die Pod-zu-Pod-Kommunikation auf explizit erlaubte Pfade beschränken. Der Kubernetes-API-Server sollte nicht direkt aus dem Internet zugänglich sein.

Authentifizierung und Autorisierung. Der API-Server darf keine anonyme Authentifizierung oder unsichere Ports aktivieren. Rollenbasierte Zugriffskontrolle (RBAC) muss aktiviert und nach Least-Privilege-Prinzipien konfiguriert sein.

Audit-Protokollierung. Die API-Server-Audit-Protokollierung muss mit einer Richtlinie aktiviert sein, die mindestens Erstell-, Aktualisierungs-, Lösch- und Abrufoperationen für sensible Ressourcentypen erfasst. Audit-Protokolle müssen an ein zentrales SIEM weitergeleitet werden.

Upgrade-Häufigkeit. Kubernetes-Versionen erhalten Sicherheitspatches für ungefähr 14 Monate nach der Veröffentlichung. Der Betrieb nicht unterstützter Kubernetes-Versionen stellt ein erhebliches Sicherheitsrisiko dar, das in Verteidigungsdeployments inakzeptabel ist.

Pod Security Standards: Das Restricted-Profil

Kubernetes Pod Security Standards (PSS) definieren drei Richtlinienprofile — Privileged, Baseline und Restricted — die zunehmende Einschränkungsebenen der Pod-Konfiguration darstellen. Das Restricted-Profil ist der geeignete Ausgangspunkt für Verteidigungs-Workloads: Es setzt die sicherheitsrelevantesten Pod-Konfigurationsbeschränkungen durch.

Das Restricted-Profil verbietet: privilegierte Container (Container mit auf true gesetztem privileged-Flag), als Root laufende Container (durchgesetzt durch runAsNonRoot: true), Container mit Zugriff auf das Host-Netzwerk, Container mit Zugriff auf Host-PIDs oder Host-IPCs, Container, die Host-Pfade als Volumes einbinden, und Container, die Linux-Capabilities über eine definierte Allowlist hinaus hinzufügen.

Die Implementierung des Restricted-Profils in einer bestehenden Kubernetes-Umgebung erfordert oft Anwendungsänderungen. Für neue Verteidigungsanwendungsentwicklung sollte die Einhaltung des Restricted-Profils von Anfang an eine Designanforderung sein.

Pod Security Standards werden durch den integrierten PodSecurity-Admission-Controller durchgesetzt. Verteidigungs-Deployments sollten den Enforce-Modus für das Restricted-Profil in allen Produktions-Namespaces verwenden.

Network Policies: Mikrosegmentierung mit Calico oder Cilium

Kubernetes Network Policies definieren, welche Pods auf IP/Port-Ebene mit welchen anderen Pods kommunizieren können. Ohne Network Policies können alle Pods in einem Cluster mit allen anderen Pods kommunizieren — eine flache Netzwerktopologie, die architektonisch mit Zero-Trust-Prinzipien unvereinbar ist. Network Policies implementieren die Mikrosegmentierungsschicht auf der Container-Netzwerkebene.

Calico ist die am weitesten verbreitete Kubernetes-Netzwerkrichtlinienimplementierung, die sowohl Standard-Kubernetes-NetworkPolicy-Ressourcen als auch Calico-spezifische GlobalNetworkPolicy- und NetworkPolicy-Ressourcen mit zusätzlichen Funktionen unterstützt. Für Air-Gapped-Verteidigungsumgebungen macht Calicos On-Premises-Deployment-Modell und das Fehlen von Cloud-Control-Plane-Abhängigkeiten es operativ geeignet.

Cilium verwendet eBPF (Extended Berkeley Packet Filter) zur Durchsetzung von Netzwerkrichtlinien im Linux-Kernel und bietet höhere Leistung als iptables-basierte Lösungen sowie Unterstützung für Layer-7-Netzwerkrichtlinien. Ciliums Hubble-Observability-Komponente bietet detaillierte Einblicke in Netzwerkflüsse.

Das Schlüsselprinzip für das Design von Verteidigungs-Network-Policies ist Default-Deny: Neue Namespaces sollten eine Standard-NetworkPolicy haben, die den gesamten eingehenden und ausgehenden Verkehr blockiert, bis explizite Erlaubnisregeln erstellt werden.

Admission Controller: Policy-as-Code mit OPA/Gatekeeper und Kyverno

Admission Controller sind Plugins, die API-Server-Anfragen abfangen, bevor sie in etcd gespeichert werden, und ermöglichen die Durchsetzung von Richtlinien auf API-Clusterebene. OPA/Gatekeeper und Kyverno sind die zwei dominanten Policy-as-Code-Frameworks für die Kubernetes-Admission-Kontrolle.

OPA/Gatekeeper verwendet die OPA (Open Policy Agent) Richtlinien-Engine mit der Rego-Richtliniensprache. Gatekeeper registriert sich als ValidatingAdmissionWebhook, der die OPA-Richtlinien-Engine für jede relevante API-Anfrage aufruft. Constraint Templates definieren die Richtlinienstruktur; Constraints instanziieren die Vorlage für spezifische Ressourcen.

Kyverno verwendet nativen Kubernetes-YAML zum Ausdrücken von Richtlinien, was es für Teams zugänglicher macht, die mit Kubernetes-Ressourcendefinitionen vertraut sind. Kyverno unterstützt sowohl Validierung (Blockierung nicht konformer Ressourcen) als auch Mutation (automatisches Hinzufügen erforderlicher Labels oder Sicherheitskontextfelder zu Ressourcen, bei denen diese fehlen).

Für Verteidigungs-Deployments sollten Admission-Control-Richtlinien mindestens durchsetzen: Image-Provenienz (Images müssen aus genehmigten Registries stammen), Image-Signierung (Images müssen gültige cosign-Signaturen haben), Sicherheitskontextanforderungen, erforderliche Labels und Ressourcenlimits.

Laufzeitsicherheit: Falco, seccomp und AppArmor

Falco (CNCF-graduiert) ist das Standard-Laufzeitsicherheitswerkzeug für Kubernetes: Es überwacht Kernel-Systemaufrufe in Echtzeit und generiert Warnungen, wenn das Verhalten verdächtigen Mustern entspricht. Falco-Regeln decken Prozessausführung, Dateizugriff, Netzwerkaktivität und Kubernetes-API-Aktivität ab. Falco integriert sich mit SIEM-Systemen über Syslog- oder Webhook-Ausgabe.

seccomp (Secure Computing Mode) Profile schränken die für Container-Prozesse verfügbaren Systemaufrufe ein. Kubernetes bietet ein Standard-seccomp-Profil (RuntimeDefault), das die gefährlichsten Systemaufrufe blockiert. Verteidigungs-Workloads sollten mindestens das RuntimeDefault-Profil verwenden.

AppArmor (auf Linux-Distributionen, die es unterstützen) stellt eine Mandatory-Access-Control-Schicht bereit, die einschränkt, auf welche Dateien, Capabilities und Netzwerkoperationen jeder Prozess zugreifen kann. AppArmor-Profile für Kubernetes-Container fügen eine Defense-in-Depth-Schicht hinzu.