Beste WAF für Kubernetes
Schützen Sie Ihre Kubernetes-Workloads mit container-nativen WAF-Lösungen. Vergleichen Sie WAFs für Ingress Controller, Gateway-API-Optionen, Sidecar-Bereitstellungen und Cloud-native Sicherheitsplattformen für EKS, GKE und AKS.
Kubernetes hat grundlegend verändert, wie wir Anwendungen bereitstellen, und erfordert einen grundlegend anderen Ansatz für den WAF-Schutz. Traditionelle, perimeterbasierte WAFs tun sich schwer mit der Dynamik von Pods, Services und kurzlebigen Workloads. Sie brauchen Sicherheit, die Kubernetes nativ versteht.
WAF-Optionen für Kubernetes lassen sich in drei Kategorien einteilen: WAFs auf Basis von Ingress Controllern, die den Verkehr am Cluster-Edge schützen, Sidecar- oder Service-Mesh-Integrationen, die einzelne Services schützen, und Cloud-native WAFs von AWS, Google und Azure, die sich in verwaltete Kubernetes-Angebote integrieren. Die richtige Wahl hängt von Ihrer Cluster-Architektur, Ihrem Cloud-Anbieter und Ihren Sicherheitsanforderungen ab.
Wichtiges Update 2026: Der Community-Controller kubernetes/ingress-nginx wurde im März 2026 eingestellt (angekündigt im November 2025, bestätigt vom Steering Committee und Security Response Committee im Januar 2026). Er erhält keine weiteren Bugfixes oder Sicherheitspatches mehr, und das Projekt empfiehlt die Migration zur Gateway API oder zu einem weiterhin gepflegten Ingress Controller. Dies ist ein eigenständiges Projekt, getrennt von F5s kommerziell unterstütztem NGINX Ingress Controller (nginx/kubernetes-ingress), der davon nicht betroffen ist. Wählen Sie Ihren Controller und Ihre WAF entsprechend.
Dieser Leitfaden bewertet WAF-Lösungen, die speziell für Kubernetes entwickelt wurden, von Open-Source-Optionen für selbst verwaltete Cluster bis zu Enterprise-Lösungen für Produktions-Workloads auf verwalteten Kubernetes-Plattformen.
Top WAF-Anbieter für Kubernetes
ModSecurity Open Source WAF
Open-Source-WahlModSecurity wird inzwischen von OWASP betreut, nachdem Trustwave es im Juli 2024 an die Open-Source-Community zurückgegeben hat, und bietet kostenlosen, praxiserprobten WAF-Schutz. Auf Kubernetes ist der aktiv gepflegte Weg der HAProxy Kubernetes Ingress Controller, der ModSecurity v3 (libmodsecurity) mit dem OWASP Core Rule Set einbettet. Vermeiden Sie das ModSecurity-Add-on des Community-Controllers kubernetes/ingress-nginx für neue Bereitstellungen; dieser Controller wurde im März 2026 eingestellt und erhält keine Sicherheitspatches mehr. Eine gepflegte Option aus NGINX plus ModSecurity finden Sie weiter unten bei BunkerWeb.
Hauptvorteile:
- Kostenlos, keine Lizenzierung pro Pod
- OWASP CRS 4.x für umfassenden Schutz
- Aktiv gepflegt über den HAProxy Ingress Controller
- Von OWASP betreute Engine (community-gepflegt seit 2024)
AWS Web Application Firewall
Beste Wahl für EKSFür Amazon-EKS-Cluster integriert sich AWS WAF nativ mit dem AWS Load Balancer Controller. Schützen Sie Ihre über ALB-Ingress exponierten Kubernetes-Services mit verwalteten Regelgruppen und einer nutzungsbasierten Preisgestaltung (eine feste monatliche Gebühr pro Web-ACL und Regel, zuzüglich einer Gebühr pro Request), die mit Ihrem Cluster skaliert.
Hauptvorteile:
- Native Integration mit AWS-ALB-Ingress
- Verwaltete Regelgruppen inklusive
- Nutzungsbasierte Preisgestaltung, die mit dem Traffic skaliert
- CloudWatch-Protokollierung und -Metriken
Coraza Web Application Firewall
Cloud-native EngineOWASP Coraza ist der speichersichere Go-Nachfolger von libModSecurity und drop-in-kompatibel mit dem OWASP Core Rule Set (SecLang-Regeln). Es läuft als Plugin für Caddy, Envoy und Traefik und ist damit eine zukunftsweisende Open-Source-WAF-Engine für Cluster, die von Ingress zur Gateway API migrieren.
Hauptvorteile:
- Speichersichere Go-Neuimplementierung von ModSecurity
- OWASP-CRS-kompatibel (SecLang-Regeln)
- Integriert sich mit Caddy, Envoy und Traefik
- Passt zu Gateway-API-Migrationen
Worauf Sie bei einer WAF für Kubernetes achten sollten
Entscheidende Faktoren bei der Auswahl einer Kubernetes-WAF:
- Ingress-Controller-Integration - Funktioniert die WAF mit Ihrem Ingress Controller (F5 NGINX, Traefik, HAProxy, Cloud-native)? Oder bringt sie eine eigene Ingress-Implementierung mit? Beachten Sie, dass der Community-Controller kubernetes/ingress-nginx seit März 2026 eingestellt ist und für neue Bereitstellungen nicht gewählt werden sollte.
- Gateway-API-Unterstützung - Die Gateway API ist GA und der empfohlene Nachfolger von Ingress. Bevorzugen Sie eine WAF, die sich an Gateway-API-Ressourcen anbindet (über Controller wie Envoy Gateway, Traefik, HAProxy oder Azure Application Gateway for Containers), um Ihre Konfiguration zukunftssicher zu machen.
- Bereitstellungsmodell - Schutz auf Ingress-Ebene deckt alle Services hinter dem Ingress ab. Eine Sidecar-Bereitstellung schützt einzelne Pods, fügt aber pro Pod zusätzlichen Ressourcen-Overhead hinzu.
- CRD-basierte Konfiguration - Kubernetes-native Konfiguration über Custom Resource Definitions ermöglicht GitOps-Workflows und Infrastructure-as-Code.
- Lizenzierung pro Pod - Enterprise-WAFs berechnen möglicherweise pro Pod oder Instanz. In großen Clustern mit hunderten Pods kann das teuer werden. Ziehen Sie zur Kostenkontrolle Open-Source-Alternativen in Betracht.
- Horizontal Pod Autoscaling - Ihre WAF muss mit Ihrer Anwendung skalieren. Stellen Sie sicher, dass sie HPA unterstützt und bei Traffic-Spitzen nicht zum Flaschenhals wird.
- Service-Mesh-Integration - Wenn Sie Istio, Linkerd oder ein anderes Service Mesh einsetzen, prüfen Sie, wie sich die WAF integriert. Manche WAFs arbeiten nur auf Ingress-Ebene, andere lassen sich mit Mesh-Sidecars integrieren.
- Observability - WAF-Logs und -Metriken sollten sich in Ihren bestehenden Kubernetes-Observability-Stack integrieren (Prometheus, Grafana, Elasticsearch, Cloud-native Logging).
Kubernetes-Überlegungen
Kubernetes-spezifische Überlegungen bei der Bereitstellung einer WAF:
- Einstellung von ingress-nginx - Der Community-Controller kubernetes/ingress-nginx wurde im März 2026 eingestellt und erhält keine weiteren Sicherheitspatches. Wenn Sie auf dessen ModSecurity-Add-on setzen, planen Sie eine Migration zur Gateway API oder zu einem weiterhin gepflegten Controller (HAProxy, Traefik, Envoy Gateway oder F5s kommerzieller NGINX Ingress Controller).
- Ingress vs. Gateway API - Die Gateway API ist inzwischen GA und bietet mehr Flexibilität als klassische Ingress-Ressourcen. Prüfen Sie, ob Ihre WAF die Gateway API unterstützt, um Ihre Konfiguration zukunftssicher zu machen; das Tool Ingress2Gateway kann die Migration automatisieren.
- Network Policies - Eine WAF auf Ingress-Ebene ergänzt Kubernetes Network Policies für den Schutz des Ost-West-Verkehrs, ersetzt sie aber nicht.
- Pod Security Standards - Stellen Sie sicher, dass Ihre WAF-Pods unter Ihren Pod Security Standards laufen können. Manche WAFs benötigen privilegierte Container oder Host-Networking.
- Resource Requests und Limits - Die WAF-Verarbeitung verbraucht CPU und Speicher. Setzen Sie passende Resource Requests/Limits, um eine Erschöpfung der Node-Ressourcen zu verhindern.
- Multi-Tenancy - Überlegen Sie in Multi-Tenant-Clustern, ob WAF-Regeln namespace-bezogen oder cluster-weit gelten sollen. CRD-basierte WAFs unterstützen häufig eine Namespace-Isolierung.
- Integration mit Cloud-Provider-WAFs - Verwaltete Kubernetes-Dienste (EKS, GKE, AKS) lassen sich auf Ebene des Load Balancers, außerhalb des Clusters, mit ihren jeweiligen Cloud-WAFs integrieren (AWS WAF, Cloud Armor, Azure WAF über Application Gateway for Containers).
- Secrets-Management - Wenn Ihre WAF API-Keys oder Zertifikate benötigt, verwenden Sie Kubernetes Secrets oder externe Secrets-Manager statt ConfigMaps.
Häufig gestellte Fragen
Sollte ich eine WAF auf Ingress-Ebene oder als Sidecars einsetzen?
Eine WAF auf Ingress-Ebene ist einfacher und schützt den gesamten Verkehr, der über diesen Ingress in den Cluster gelangt. Eine Sidecar-Bereitstellung (eine WAF pro Pod) bietet granulareren Schutz und kann Ost-West-Verkehr zwischen Services absichern, fügt aber Ressourcen-Overhead und Komplexität hinzu. Die meisten Teams beginnen mit einer WAF auf Ingress-Ebene und ergänzen bei Bedarf Sidecar-Schutz für Services mit hohen Sicherheitsanforderungen.
Wie schütze ich den Verkehr zwischen Services (Ost-West)?
Ingress-WAFs schützen nur den Nord-Süd-Verkehr, der in den Cluster gelangt. Für den Schutz des Ost-West-Verkehrs empfiehlt sich ein Service Mesh mit Sicherheitsrichtlinien (Istio, Linkerd), als Sidecar bereitgestellte WAFs oder Network Policies. Viele Angriffe gehen von kompromittierten Pods aus, wodurch Ost-West-Sicherheit zunehmend wichtiger wird.
Ist der Community-NGINX-Ingress-Controller für WAF-Zwecke noch sicher nutzbar?
Nein. Der Community-Controller kubernetes/ingress-nginx wurde im März 2026 eingestellt (angekündigt im November 2025) und erhält keine weiteren Bugfixes oder Sicherheitspatches mehr. Bestehende Installationen laufen weiter, aber Sie sollten darauf keine neuen WAF-Bereitstellungen mehr aufbauen. Migrieren Sie zur Gateway API oder nutzen Sie einen weiterhin gepflegten Controller wie HAProxy oder Traefik. Beachten Sie, dass es sich hierbei um ein anderes Projekt handelt als F5s kommerziellen NGINX Ingress Controller (nginx/kubernetes-ingress), der weiterhin unterstützt wird und die Basis für F5 WAF for NGINX bildet.
Kann ich ModSecurity weiterhin mit einem NGINX Ingress Controller verwenden?
Das ModSecurity-Add-on des Community-Controllers kubernetes/ingress-nginx wird nicht mehr empfohlen, da dieser Controller im März 2026 eingestellt wurde und keine Sicherheitsupdates mehr erhält. Für einen weiterhin gepflegten ModSecurity-Weg auf Kubernetes nutzen Sie den HAProxy Kubernetes Ingress Controller, der ModSecurity v3 mit dem OWASP Core Rule Set einbettet, oder BunkerWeb (NGINX plus ModSecurity mit Web-UI). Für die Gateway API und moderne Proxy-Stacks ist OWASP Coraza eine drop-in-fähige, CRS-kompatible Nachfolger-Engine. F5s kommerzieller NGINX Ingress Controller ist stattdessen mit F5 WAF for NGINX statt mit dem Open-Source-ModSecurity-Modul gekoppelt.
Wie wirkt sich eine WAF auf die Performance in Kubernetes aus?
Eine WAF fügt jedem Request Latenz hinzu, typischerweise 1-10 ms, je nach Komplexität der Regeln. Bei einer WAF auf Ingress-Ebene fällt dieser Overhead pro Request an, der in den Cluster gelangt. Planen Sie zusätzliche CPU- und Speicherkapazität für Ihre Ingress-Controller-Pods ein. Überwachen Sie die Antwortzeiten nach Aktivierung der WAF und passen Sie die Regeln bei Bedarf an.
Wie handhabe ich eine WAF für mehrere Namespaces oder Teams?
Nutzen Sie CRD-basierte WAFs, die namespace-bezogene Richtlinien unterstützen. So kann jedes Team seine eigenen WAF-Regeln für seinen Namespace verwalten, während Cluster-Administratoren globale Richtlinien pflegen. F5 WAF for NGINX und einige ModSecurity-Helm-Bereitstellungen unterstützen dieses Muster.
Sollte ich die WAF meines Cloud-Anbieters oder eine Kubernetes-native Lösung verwenden?
Cloud-WAFs (AWS WAF, Cloud Armor, Azure WAF) arbeiten auf Ebene des Load Balancers außerhalb Ihres Clusters und bieten DDoS-Schutz sowie verwaltete Regeln. Kubernetes-native WAFs laufen innerhalb des Clusters und haben eine bessere Sicht auf Pod- und Service-Kontext. Für umfassenden Schutz nutzen Sie beides: die Cloud-WAF am Edge und die Kubernetes-WAF auf Ingress-Ebene.