Die Dominanz von Kubernetes im Enterprise-Sektor hat eine spürbare Kehrseite: Der De-facto-Standard für Container-Orchestrierung steht im Fadenkreuz hochgradig automatisierter Angriffswellen. Messungen von Sicherheitsanbietern wie Palo Alto Networks, Aqua Security und Wiz belegen eine alarmierende Geschwindigkeit: Wird ein ungeschützter Cluster mit öffentlich erreichbaren Schnittstellen ins Netz gestellt, vergehen in vielen Fällen kaum zwanzig Minuten, bis erste automatisierte Angriffsversuche registriert werden. Botnetze scannen das Internet permanent nach exponierten Kubelet-Ports, ungesicherten API-Servern oder anfälligen Dashboard-Endpunkten ab, um Krypto-Miner zu platzieren oder Zugangsdaten für das Cloud-Umfeld abzugreifen.

Das inhärente Dilemma: „Open by Design“ vs. Zero Trust

Die zugrundeliegende Ursache für viele Sicherheitslücken liegt in der ursprünglichen Philosophie des Systems. Wie Cloud-Native-Analysen und Auswertungen der Cloud Native Computing Foundation (CNCF) verdeutlichen, wurde Kubernetes primär auf Entwicklerfreundlichkeit, Ausfallsicherheit und flexible Interoperabilität ausgelegt. Das Standardverhalten eines neu initialisierten Clusters entspricht einem offenen Modell: Jedes Pod kann grundsätzlich mit jedem anderen Pod über das flache Overlay-Netzwerk kommunizieren, Namensräume bieten primär logische Ordnung und ohne explizite Konfiguration agieren Service-Accounts mit weit gefassten Default-Tokens.

Angreifer, denen der Einbruch über eine verwundbare Web-Applikation in einem Container gelingt, nutzen dieses flache Design gezielt für laterale Bewegungen (Lateral Movement). Durch das Auslesen gemounteter Service-Account-Tokens unter /var/run/secrets/kubernetes.io/serviceaccount wird häufig direkt der Kubernetes-API-Server sondiert, um Berechtigungen zu eskalieren oder benachbarte Workloads im selben Node zu kompromittieren.

Netzwerk-Mikrosegmentierung als unverzichtbare Bastion

Eine der gravierendsten Versäumnisse in Produktivumgebungen ist das Fehlen konsistenter Netzwerksegmentierung. Da native Kubernetes-Installationen ohne CNI-Plugin mit NetworkPolicy-Unterstützung (wie Calico, Cilium oder Flannel mit Extensions) Netzwerkregeln ignorieren, wiegen sich Teams oft in falscher Sicherheit. Eine robuste Sicherheitsarchitektur verlangt zwingend eine standardmäßige Default-Deny-Policy auf Namespace-Ebene, die sämtlichen Ingress- und Egress-Verkehr blockiert, bis er explizit freigegeben wird:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Erst auf dieser isolierten Basis sollten feingranulare Regeln definiert werden, die ausschließlich die notwendigen Kommunikationspfade – etwa vom Ingress-Controller zum Frontend-Pod und von dort zur Datenbank auf einem dedizierten Port – autorisieren. Moderne CNI-Lösungen auf Basis von eBPF ermöglichen es zudem, diese Filterung auf Layer-7-Ebene (HTTP-Methoden, gRPC) auszudehnen, ohne nennenswerte Performance-Einbußen im Kernel zu verursachen.

Pod Security Standards und Admission Control

Neben dem Netzwerk muss die Ausführungsumgebung auf Node-Ebene drastisch reglementiert werden. Mit der Ablösung der veralteten PodSecurityPolicies durch native Pod Security Standards (PSS) und den integrierten Pod Security Admission Controller steht Administratoren ein effektives Werkzeug zur Verfügung. Für geschäftskritische Workloads sollte der Modus Restricted forciert werden, der Container daran hindert, als Root-User zu laufen, Privileges zu eskalieren oder Host-Namespaces (IPC, PID, Network) zu teilen:

• Erzwingung von Non-Root: Container-Images müssen mit fest definierten UIDs ohne Root-Rechte ausgeführt werden (runAsNonRoot: true).
• Root-Dateisystem read-only: Durch readOnlyRootFilesystem: true wird verhindert, dass eingeschleuste Malware Binärdateien auf dem lokalen Dateisystem ablegt oder Skripte modifiziert.
• Capabilities strippen: Sämtliche Linux-Capabilities sollten standardmäßig mit drop: ["ALL"] entfernt und nur im absoluten Ausnahmefall minimal ergänzt werden (z. B. NET_BIND_SERVICE).

Ganzheitliche DevSecOps-Pipeline und Runtime-Monitoring

Cluster-Härtung endet nicht bei der Manifest-Konfiguration. Ein belastbares Schutzkonzept muss die gesamte Software-Lieferkette einbinden. Schwachstellenscanner in CI/CD-Pipelines identifizieren veraltete Basispakete und CVEs, bevor Images in die Registry gelangen. Admission Controller wie Kyverno oder Open Policy Agent (OPA) Gatekeeper stellen sicher, dass ausschließlich kryptografisch signierte Images (beispielsweise via Sigstore/Cosign) im Cluster deployt werden können.

Für die Runtime-Ebene setzen moderne Infrastrukturen auf verhaltensbasierte Anomalie-Erkennung. Tools wie Falco überwachen Linux-Systemaufrufe direkt im Kernel via eBPF. Sobald ein Container unerwartet eine Shell spawnt, Mount-Operationen durchführt oder verdächtige Verzeichnisse wie /etc/shadow liest, generiert die Engine Echtzeit-Alerts oder trennt den kompromittierten Pod isoliert vom Netzwerk.