Meilleur WAF pour Kubernetes
Protégez vos workloads Kubernetes avec des solutions WAF natives aux conteneurs. Comparez les WAF de contrôleurs Ingress, les options Gateway API, les déploiements en sidecar et les plateformes de sécurité cloud-native pour EKS, GKE et AKS.
Kubernetes a fondamentalement changé notre façon de déployer les applications, et cela exige une approche radicalement différente de la protection WAF. Les WAF périmétriques traditionnels peinent face à la nature dynamique des pods, des services et des workloads éphémères. Il vous faut une sécurité qui parle nativement le langage de Kubernetes.
Les options WAF pour Kubernetes se répartissent en trois catégories : les WAF basés sur un contrôleur Ingress, qui protègent le trafic à la périphérie du cluster ; les intégrations sidecar ou service mesh, qui protègent des services individuels ; et les WAF cloud-native d'AWS, de Google et d'Azure, qui s'intègrent aux offres Kubernetes managées. Le bon choix dépend de l'architecture de votre cluster, de votre fournisseur cloud et de vos exigences de sécurité.
Mise à jour importante 2026 : le contrôleur communautaire kubernetes/ingress-nginx a été retiré en mars 2026 (annonce en novembre 2025, confirmée par le Steering Committee et le Security Response Committee en janvier 2026). Il ne reçoit plus aucun correctif de bug ni patch de sécurité, et le projet recommande de migrer vers la Gateway API ou vers un contrôleur Ingress activement maintenu. Il s'agit d'un projet distinct du NGINX Ingress Controller supporté commercialement par F5 (nginx/kubernetes-ingress), qui n'est pas concerné. Choisissez votre contrôleur et votre WAF en conséquence.
Ce guide évalue des solutions WAF spécifiquement conçues pour Kubernetes, des options open source pour les clusters autogérés aux solutions entreprise pour les workloads de production sur des plateformes Kubernetes managées.
Meilleurs fournisseurs WAF pour Kubernetes
F5 WAF pour NGINX
Leader entrepriseF5 WAF for NGINX (anciennement NGINX App Protect WAF) s'exécute sur le NGINX Ingress Controller supporté commercialement par F5 (nginx/kubernetes-ingress), un projet distinct et toujours activement maintenu, à ne pas confondre avec le projet communautaire kubernetes/ingress-nginx désormais retiré. Il se déploie nativement au sein des pods de votre contrôleur Ingress, offrant une protection par requête grâce à l'intelligence sur les menaces de F5 et plus de 7 500 signatures. Sa configuration déclarative via des CRD Kubernetes (APPolicy, APLogConf, APUserSig) s'intègre parfaitement aux workflows GitOps.
Avantages clés :
- S'exécute sur le NGINX Ingress Controller supporté par F5, pas sur le projet communautaire retiré
- CRD Kubernetes pour une configuration déclarative
- Intelligence sur les menaces F5 avec plus de 7 500 signatures
- Politiques de protection par pod ou par Ingress
ModSecurity
Meilleur open sourceModSecurity, désormais sous la responsabilité de l'OWASP depuis que Trustwave l'a rendu à la communauté open source en juillet 2024, offre une protection WAF gratuite et éprouvée. Sur Kubernetes, la voie activement maintenue est le HAProxy Kubernetes Ingress Controller, qui embarque ModSecurity v3 (libmodsecurity) avec l'OWASP Core Rule Set. Évitez le module complémentaire ModSecurity du contrôleur communautaire kubernetes/ingress-nginx pour tout nouveau déploiement ; ce contrôleur a été retiré en mars 2026 et ne reçoit plus de correctifs de sécurité. Pour une option NGINX plus ModSecurity toujours maintenue, voir BunkerWeb ci-dessous.
Avantages clés :
- Gratuit, sans licence par pod
- OWASP CRS 4.x pour une protection complète
- Activement maintenu via le HAProxy Ingress Controller
- Moteur sous la responsabilité de l'OWASP (maintenu par la communauté depuis 2024)
Wallarm API Security Platform
Sécurité APIWallarm propose une plateforme WAAP cloud-native avec des options de déploiement natives à Kubernetes, notamment l'injection en sidecar et l'intégration au contrôleur Ingress. Pour les clusters exécutant des microservices à forte intensité d'API, les capacités de découverte et de protection d'API de Wallarm couvrent des menaces que les WAF traditionnels laissent passer.
Avantages clés :
- Options de déploiement en sidecar ou via Ingress
- Découverte d'API à travers les services
- Déploiement en cloud ou sur nœuds autohébergés
- Tests de sécurité intégrés (DAST)
AWS Web Application Firewall
Meilleur pour EKSPour les clusters Amazon EKS, AWS WAF s'intègre nativement à l'AWS Load Balancer Controller. Protégez vos services Kubernetes exposés via un Ingress ALB grâce à des groupes de règles managés et une tarification à l'usage (un forfait mensuel fixe par ACL web et par règle, plus un coût par requête) qui évolue avec votre cluster.
Avantages clés :
- Intégration native avec l'Ingress ALB d'AWS
- Groupes de règles managés inclus
- Tarification à l'usage qui évolue avec le trafic
- Journalisation et métriques CloudWatch
Google Cloud Armor
Meilleur pour GKEGoogle Cloud Armor fournit une protection WAF et DDoS pour les clusters GKE utilisant le GKE Gateway Controller ou Ingress. Sa protection adaptative basée sur le ML, ses règles préconfigurées reposant sur l'OWASP Core Rule Set (CRS 4.x) et son intégration au réseau mondial de Google en font le choix naturel pour les déploiements GKE.
Avantages clés :
- Intégration native avec l'Ingress/Gateway GKE
- Protection adaptative pilotée par le ML
- Réseau mondial de Google pour la protection DDoS
- Règles WAF préconfigurées basées sur l'OWASP CRS 4.x
Azure Web Application Firewall
Meilleur pour AKSPour Azure Kubernetes Service, Application Gateway for Containers est l'ingress managé conçu spécifiquement pour appliquer les politiques Azure WAF au trafic du cluster. Configuré via des ressources Ingress ou Gateway API par l'intermédiaire de l'ALB Controller, il exécute le plan de données WAF en dehors du cluster avec le Microsoft Default Rule Set. C'est le choix natif naturel pour AKS, à l'image d'AWS WAF pour EKS et de Cloud Armor pour GKE.
Avantages clés :
- Plan de données WAF managé par Azure pour AKS
- Configuré via Ingress ou Gateway API (ALB Controller)
- Règles managées du Microsoft Default Rule Set
- Application Gateway Ingress Controller (AGIC) également disponible
BunkerWeb Open Source WAF
Open source moderneBunkerWeb peut se déployer comme contrôleur Ingress Kubernetes ou comme reverse proxy autonome, offrant une protection WAF gratuite avec une interface web conviviale. Construit sur NGINX avec ModSecurity et l'OWASP Core Rule Set, c'est une alternative activement maintenue au projet communautaire ingress-nginx désormais retiré, pour les équipes qui veulent une protection de niveau NGINX plus ModSecurity sans la complexité de configuration.
Avantages clés :
- Mode contrôleur Ingress Kubernetes
- Interface web pour la configuration
- ModSecurity + OWASP CRS inclus
- Déploiement via Docker et Helm
Coraza Web Application Firewall
Moteur cloud-nativeOWASP Coraza est le successeur de libModSecurity écrit en Go memory-safe, compatible sans modification avec l'OWASP Core Rule Set (règles seclang). Il s'exécute comme plugin pour Caddy, Envoy et Traefik, ce qui en fait un moteur WAF open source tourné vers l'avenir pour les clusters migrant d'Ingress vers la Gateway API.
Avantages clés :
- Réécriture de ModSecurity en Go memory-safe
- Compatible OWASP CRS (règles seclang)
- S'intègre avec Caddy, Envoy et Traefik
- Adapté aux migrations vers la Gateway API
Ce qu'il faut rechercher dans un WAF pour Kubernetes
Facteurs déterminants pour choisir un WAF Kubernetes :
- Intégration au contrôleur Ingress - Le WAF fonctionne-t-il avec votre contrôleur Ingress (F5 NGINX, Traefik, HAProxy, solutions cloud-native) ? Ou fournit-il sa propre implémentation Ingress ? Notez que le contrôleur communautaire kubernetes/ingress-nginx est retiré depuis mars 2026 et ne doit pas être choisi pour de nouveaux déploiements.
- Support de la Gateway API - La Gateway API est désormais disponible en version stable (GA) et constitue le successeur recommandé d'Ingress. Privilégiez un WAF qui s'attache aux ressources Gateway API (via des contrôleurs tels qu'Envoy Gateway, Traefik, HAProxy ou Azure Application Gateway for Containers) afin de pérenniser votre configuration.
- Modèle de déploiement - La protection au niveau Ingress couvre tous les services situés derrière l'Ingress. Le déploiement en sidecar protège des pods individuels, mais ajoute une surcharge de ressources par pod.
- Configuration à base de CRD - Une configuration native à Kubernetes via des Custom Resource Definitions permet les workflows GitOps et l'infrastructure as code.
- Licence par pod - Les WAF entreprise peuvent facturer par pod ou par instance. Dans les grands clusters comptant des centaines de pods, cela peut devenir coûteux. Envisagez des alternatives open source pour maîtriser les coûts.
- Mise à l'échelle horizontale des pods (HPA) - Votre WAF doit évoluer avec votre application. Assurez-vous qu'il prend en charge le HPA et qu'il ne devient pas un goulot d'étranglement lors des pics de trafic.
- Intégration au service mesh - Si vous utilisez Istio, Linkerd ou un autre service mesh, vérifiez comment le WAF s'y intègre. Certains WAF n'opèrent qu'au niveau Ingress ; d'autres peuvent s'intégrer aux sidecars du mesh.
- Observabilité - Les logs et métriques du WAF doivent s'intégrer à votre stack d'observabilité Kubernetes existante (Prometheus, Grafana, Elasticsearch, journalisation cloud-native).
Considérations Kubernetes
Considérations spécifiques au déploiement d'un WAF sur Kubernetes :
- Retrait d'ingress-nginx - Le contrôleur communautaire kubernetes/ingress-nginx a été retiré en mars 2026 et ne reçoit plus aucun patch de sécurité. Si vous dépendez de son module complémentaire ModSecurity, planifiez une migration vers la Gateway API ou vers un contrôleur maintenu (HAProxy, Traefik, Envoy Gateway ou le NGINX Ingress Controller commercial de F5).
- Ingress ou Gateway API - La Gateway API est désormais disponible en version stable (GA) et offre davantage de flexibilité que les ressources Ingress traditionnelles. Vérifiez si votre WAF prend en charge la Gateway API pour pérenniser votre configuration ; l'outil Ingress2Gateway peut aider à automatiser la migration.
- Network Policies - Un WAF au niveau Ingress complète les Network Policies Kubernetes pour la protection du trafic est-ouest, mais ne les remplace pas.
- Pod Security Standards - Assurez-vous que les pods de votre WAF peuvent s'exécuter sous vos Pod Security Standards. Certains WAF nécessitent des conteneurs privilégiés ou l'accès au réseau de l'hôte (host networking).
- Requests et limits de ressources - Le traitement WAF consomme du CPU et de la mémoire. Définissez des requests/limits de ressources appropriés pour éviter l'épuisement des ressources des nœuds.
- Multi-tenant - Dans les clusters multi-tenant, déterminez si les règles WAF doivent être limitées au namespace ou s'appliquer à l'ensemble du cluster. Les WAF à base de CRD prennent souvent en charge l'isolation par namespace.
- Intégration au WAF du fournisseur cloud - Les services Kubernetes managés (EKS, GKE, AKS) peuvent s'intégrer à leur WAF cloud respectif (AWS WAF, Cloud Armor, Azure WAF via Application Gateway for Containers) au niveau du load balancer, en dehors du cluster.
- Gestion des secrets - Si votre WAF nécessite des clés API ou des certificats, utilisez des Secrets Kubernetes ou un gestionnaire de secrets externe plutôt que des ConfigMaps.
Questions fréquentes
Dois-je utiliser un WAF au niveau Ingress ou en sidecars ?
Un WAF au niveau Ingress est plus simple et protège tout le trafic entrant dans le cluster via cet Ingress. Le déploiement en sidecar (un WAF par pod) offre une protection plus granulaire et peut protéger le trafic est-ouest entre services, mais ajoute une surcharge de ressources et de complexité. La plupart des équipes commencent par un WAF au niveau Ingress, puis ajoutent une protection en sidecar pour les services à forte exigence de sécurité si nécessaire.
Comment protéger le trafic entre services (est-ouest) ?
Les WAF Ingress ne protègent que le trafic nord-sud entrant dans le cluster. Pour la protection est-ouest, envisagez un service mesh avec des politiques de sécurité (Istio, Linkerd), des WAF déployés en sidecar, ou des network policies. De nombreuses attaques proviennent de pods compromis, ce qui rend la sécurité est-ouest de plus en plus importante.
Le contrôleur communautaire NGINX Ingress est-il encore sûr pour un usage WAF ?
Non. Le contrôleur communautaire kubernetes/ingress-nginx a été retiré en mars 2026 (annonce en novembre 2025) et ne reçoit plus aucun correctif de bug ni patch de sécurité. Les installations existantes continuent de fonctionner, mais vous ne devriez pas bâtir de nouveaux déploiements WAF dessus. Migrez vers la Gateway API, ou utilisez un contrôleur maintenu comme HAProxy ou Traefik. Notez qu'il s'agit d'un projet différent du NGINX Ingress Controller commercial de F5 (nginx/kubernetes-ingress), qui reste supporté et constitue la base de F5 WAF for NGINX.
Puis-je encore utiliser ModSecurity avec un NGINX Ingress Controller ?
Le module complémentaire ModSecurity du contrôleur communautaire kubernetes/ingress-nginx n'est plus recommandé, car ce contrôleur a été retiré en mars 2026 et ne reçoit plus de mises à jour de sécurité. Pour une voie ModSecurity maintenue sur Kubernetes, utilisez le HAProxy Kubernetes Ingress Controller, qui embarque ModSecurity v3 avec l'OWASP Core Rule Set, ou BunkerWeb (NGINX plus ModSecurity avec une interface web). Pour la Gateway API et les stacks de proxy modernes, OWASP Coraza constitue un moteur successeur compatible CRS, à intégrer sans modification. Le NGINX Ingress Controller commercial de F5 s'associe quant à lui à F5 WAF for NGINX plutôt qu'au module ModSecurity open source.
Quel est l'impact du WAF sur les performances dans Kubernetes ?
Un WAF ajoute de la latence à chaque requête, généralement entre 1 et 10 ms selon la complexité des règles. Pour un WAF au niveau Ingress, cette surcharge s'applique à chaque requête entrant dans le cluster. Prévoyez du CPU et de la mémoire supplémentaires pour les pods de votre contrôleur Ingress. Surveillez les temps de réponse après l'activation du WAF et ajustez les règles si nécessaire.
Comment gérer le WAF pour plusieurs namespaces ou équipes ?
Utilisez des WAF à base de CRD prenant en charge des politiques limitées au namespace. Chaque équipe peut ainsi gérer ses propres règles WAF pour son namespace, tandis que les administrateurs du cluster conservent des politiques globales. F5 WAF for NGINX et certains déploiements Helm de ModSecurity prennent en charge ce modèle.
Dois-je utiliser le WAF de mon fournisseur cloud ou une solution native à Kubernetes ?
Les WAF cloud (AWS WAF, Cloud Armor, Azure WAF) opèrent au niveau du load balancer, en dehors de votre cluster, en fournissant protection DDoS et règles managées. Les WAF natifs à Kubernetes s'exécutent à l'intérieur du cluster avec une meilleure visibilité sur le contexte des pods et des services. Pour une protection complète, utilisez les deux : le WAF cloud en périphérie, et le WAF Kubernetes au niveau Ingress.