Best WAF for Kubernetes
Protect your Kubernetes workloads with container-native WAF solutions. Compare Ingress Controller WAFs, Gateway API options, sidecar deployments, and cloud-native security platforms for EKS, GKE, and AKS.
Kubernetes has fundamentally changed how we deploy applications, and it requires a fundamentally different approach to WAF protection. Traditional perimeter-based WAFs struggle with the dynamic nature of pods, services, and ephemeral workloads. You need security that speaks Kubernetes natively.
WAF options for Kubernetes fall into three categories: Ingress Controller-based WAFs that protect traffic at the cluster edge, sidecar or service mesh integrations that protect individual services, and cloud-native WAFs from AWS, Google, and Azure that integrate with managed Kubernetes offerings. The right choice depends on your cluster architecture, cloud provider, and security requirements.
Important 2026 update: the community kubernetes/ingress-nginx controller was retired in March 2026 (announced November 2025, confirmed by the Steering Committee and Security Response Committee in January 2026). It receives no further bugfixes or security patches, and the project recommends migrating to the Gateway API or a maintained Ingress controller. This is a separate project from F5's commercially supported NGINX Ingress Controller (nginx/kubernetes-ingress), which is unaffected. Choose your controller and WAF accordingly.
This guide evaluates WAF solutions specifically designed for Kubernetes, from open-source options for self-managed clusters to enterprise solutions for production workloads on managed Kubernetes platforms.
Top WAF Providers for Kubernetes
F5 WAF for NGINX
Enterprise LeaderF5 WAF for NGINX (formerly NGINX App Protect WAF) runs on F5's commercially supported NGINX Ingress Controller (nginx/kubernetes-ingress), a separate, still-maintained project distinct from the retired community kubernetes/ingress-nginx. It deploys natively within your Ingress Controller pods, providing per-request protection with F5's threat intelligence and 7,500+ signatures. Declarative configuration via Kubernetes CRDs (APPolicy, APLogConf, APUserSig) fits GitOps workflows perfectly.
Key Benefits:
- Runs on F5's supported NGINX Ingress Controller, not the retired community one
- Kubernetes CRDs for declarative config
- F5 threat intelligence with 7,500+ signatures
- Per-pod or per-Ingress protection policies
ModSecurity Open Source WAF
Open Source ChoiceModSecurity, now stewarded by OWASP after Trustwave returned it to the open-source community in July 2024, delivers free, battle-tested WAF protection. On Kubernetes the actively maintained path is the HAProxy Kubernetes Ingress Controller, which embeds ModSecurity v3 (libmodsecurity) with the OWASP Core Rule Set. Avoid the community kubernetes/ingress-nginx ModSecurity add-on for new deployments; that controller was retired in March 2026 and no longer receives security patches. For a maintained NGINX plus ModSecurity option, see BunkerWeb below.
Key Benefits:
- Free with no per-pod licensing
- OWASP CRS 4.x for comprehensive protection
- Actively maintained via the HAProxy Ingress Controller
- OWASP-stewarded engine (community-maintained since 2024)
Wallarm API Security Platform
API SecurityWallarm provides a cloud-native WAAP platform with Kubernetes-native deployment options including sidecar injection and Ingress Controller integration. For clusters running API-heavy microservices, Wallarm's API discovery and protection capabilities address threats that traditional WAFs miss.
Key Benefits:
- Sidecar and Ingress deployment options
- API discovery across services
- Cloud and self-hosted node deployment
- Integrated security testing (DAST)
AWS Web Application Firewall
Best for EKSFor Amazon EKS clusters, AWS WAF integrates natively with the AWS Load Balancer Controller. Protect your Kubernetes services exposed via ALB Ingress with managed rule groups and usage-based pricing (a fixed monthly fee per web ACL and rule, plus a per-request charge) that scales with your cluster.
Key Benefits:
- Native AWS ALB Ingress integration
- Managed rule groups included
- Usage-based pricing that scales with traffic
- CloudWatch logging and metrics
Google Cloud Armor
Best for GKEGoogle Cloud Armor provides WAF and DDoS protection for GKE clusters using the GKE Gateway Controller or Ingress. ML-based adaptive protection, preconfigured rules based on the OWASP Core Rule Set (CRS 4.x), and integration with Google's global network make it the natural choice for GKE deployments.
Key Benefits:
- Native GKE Ingress/Gateway integration
- ML-powered adaptive protection
- Google global network for DDoS
- Preconfigured WAF rules based on OWASP CRS 4.x
Azure Web Application Firewall
Best for AKSFor Azure Kubernetes Service, Application Gateway for Containers is the purpose-built managed ingress that applies Azure WAF policies to cluster traffic. Configured through Ingress or Gateway API resources via the ALB Controller, it runs the WAF data plane outside the cluster with the Microsoft Default Rule Set. It is the natural native choice for AKS, matching AWS WAF for EKS and Cloud Armor for GKE.
Key Benefits:
- Azure-managed WAF data plane for AKS
- Configured via Ingress or Gateway API (ALB Controller)
- Microsoft Default Rule Set managed rules
- Application Gateway Ingress Controller (AGIC) also available
BunkerWeb Open Source WAF
Modern Open SourceBunkerWeb can be deployed as a Kubernetes Ingress Controller or standalone reverse proxy, providing free WAF protection with a user-friendly web UI. Built on NGINX with ModSecurity and the OWASP Core Rule Set, it is an actively maintained alternative to the retired community ingress-nginx for teams wanting NGINX plus ModSecurity-level protection without the configuration complexity.
Key Benefits:
- Kubernetes Ingress Controller mode
- Web UI for configuration
- ModSecurity + OWASP CRS included
- Docker and Helm deployment
Coraza Web Application Firewall
Cloud-Native EngineOWASP Coraza is the memory-safe Go successor to libModSecurity, drop-in compatible with the OWASP Core Rule Set (seclang rules). It runs as a plugin for Caddy, Envoy, and Traefik, which makes it a forward-looking open-source WAF engine for clusters migrating off Ingress to the Gateway API.
Key Benefits:
- Memory-safe Go rewrite of ModSecurity
- OWASP CRS compatible (seclang rules)
- Integrates with Caddy, Envoy, and Traefik
- Fits Gateway API migrations
What to Look For in a WAF for Kubernetes
Critical factors for selecting a Kubernetes WAF:
- Ingress Controller Integration - Does the WAF work with your Ingress Controller (F5 NGINX, Traefik, HAProxy, cloud-native)? Or does it provide its own Ingress implementation? Note that the community kubernetes/ingress-nginx controller is retired as of March 2026 and should not be chosen for new deployments.
- Gateway API Support - The Gateway API is GA and is the recommended successor to Ingress. Prefer a WAF that attaches to Gateway API resources (via controllers such as Envoy Gateway, Traefik, HAProxy, or Azure Application Gateway for Containers) to future-proof your configuration.
- Deployment Model - Ingress-level protection covers all services behind the Ingress. Sidecar deployment protects individual pods but adds resource overhead per pod.
- CRD-Based Configuration - Kubernetes-native configuration via Custom Resource Definitions enables GitOps workflows and infrastructure-as-code.
- Per-Pod Licensing - Enterprise WAFs may charge per pod or instance. In large clusters with hundreds of pods, this can become expensive. Consider open-source alternatives for cost control.
- Horizontal Pod Autoscaling - Your WAF must scale with your application. Ensure it supports HPA and doesn't become a bottleneck during traffic spikes.
- Service Mesh Integration - If you use Istio, Linkerd, or another service mesh, check how the WAF integrates. Some WAFs work at the Ingress level only; others can integrate with mesh sidecars.
- Observability - WAF logs and metrics should integrate with your existing Kubernetes observability stack (Prometheus, Grafana, Elasticsearch, cloud-native logging).
Kubernetes Considerations
Kubernetes-specific WAF deployment considerations:
- ingress-nginx Retirement - The community kubernetes/ingress-nginx controller was retired in March 2026 with no further security patches. If you rely on its ModSecurity add-on, plan a migration to the Gateway API or a maintained controller (HAProxy, Traefik, Envoy Gateway, or F5's commercial NGINX Ingress Controller).
- Ingress vs Gateway API - The Gateway API is now GA and offers more flexibility than traditional Ingress resources. Check if your WAF supports Gateway API for future-proofing your configuration; the Ingress2Gateway tool can help automate migration.
- Network Policies - WAF at the Ingress level complements but doesn't replace Kubernetes Network Policies for east-west traffic protection.
- Pod Security Standards - Ensure your WAF pods can run under your Pod Security Standards. Some WAFs require privileged containers or host networking.
- Resource Requests and Limits - WAF processing consumes CPU and memory. Set appropriate resource requests/limits to prevent node resource exhaustion.
- Multi-Tenancy - In multi-tenant clusters, consider whether WAF rules should be namespace-scoped or cluster-wide. CRD-based WAFs often support namespace isolation.
- Cloud Provider WAF Integration - Managed Kubernetes services (EKS, GKE, AKS) can integrate with their respective cloud WAFs (AWS WAF, Cloud Armor, Azure WAF via Application Gateway for Containers) at the load balancer level, outside the cluster.
- Secrets Management - If your WAF requires API keys or certificates, use Kubernetes Secrets or external secrets managers rather than ConfigMaps.
Frequently Asked Questions
Should I use a WAF at the Ingress level or as sidecars?
Ingress-level WAF is simpler and protects all traffic entering the cluster through that Ingress. Sidecar deployment (one WAF per pod) provides more granular protection and can protect east-west traffic between services, but adds resource overhead and complexity. Most teams start with Ingress-level WAF and add sidecar protection for high-security services if needed.
How do I protect traffic between services (east-west)?
Ingress WAFs only protect north-south traffic entering the cluster. For east-west protection, consider a service mesh with security policies (Istio, Linkerd), sidecar-deployed WAFs, or network policies. Many attacks originate from compromised pods, making east-west security increasingly important.
Is the community NGINX Ingress Controller still safe to use for WAF?
No. The community kubernetes/ingress-nginx controller was retired in March 2026 (announced November 2025) and receives no further bugfixes or security patches. Existing installs keep running, but you should not build new WAF deployments on it. Migrate to the Gateway API, or use a maintained controller such as HAProxy or Traefik. Note this is a different project from F5's commercial NGINX Ingress Controller (nginx/kubernetes-ingress), which is still supported and is the base for F5 WAF for NGINX.
Can I still use ModSecurity with an NGINX Ingress Controller?
The community kubernetes/ingress-nginx ModSecurity add-on is no longer recommended because that controller was retired in March 2026 with no security updates. For a maintained ModSecurity path on Kubernetes, use the HAProxy Kubernetes Ingress Controller, which embeds ModSecurity v3 with the OWASP Core Rule Set, or BunkerWeb (NGINX plus ModSecurity with a web UI). For Gateway API and modern proxy stacks, OWASP Coraza is a drop-in, CRS-compatible successor engine. F5's commercial NGINX Ingress Controller instead pairs with F5 WAF for NGINX rather than the open-source ModSecurity module.
What's the performance impact of WAF on Kubernetes?
WAF adds latency to every request, typically 1-10ms depending on rule complexity. For Ingress-level WAF, this overhead is per-request entering the cluster. Plan for additional CPU and memory in your Ingress Controller pods. Monitor response times after enabling WAF and tune rules if needed.
How do I handle WAF for multiple namespaces or teams?
Use CRD-based WAFs that support namespace-scoped policies. This allows each team to manage their own WAF rules for their namespace while cluster admins maintain global policies. F5 WAF for NGINX and some ModSecurity Helm deployments support this pattern.
Should I use my cloud provider's WAF or a Kubernetes-native solution?
Cloud WAFs (AWS WAF, Cloud Armor, Azure WAF) operate at the load balancer level outside your cluster, providing DDoS protection and managed rules. Kubernetes-native WAFs run inside the cluster with better visibility into pod and service context. For comprehensive protection, use both: cloud WAF at the edge, Kubernetes WAF at the Ingress.