Qu’est-ce qu’un WAF Kubernetes ?

Un WAF Kubernetes est un pare-feu d’application web utilisé pour protéger les applications web et les API exécutées dans des environnements Kubernetes contre le trafic malveillant de couche d'application. Il s’agit d’un élément important de la sécurité de Kubernetes.

Kubernetes facilite le déploiement, la mise à l’échelle, et la gestion des applications conteneurisées, mais ne protège pas automatiquement ces applications contre des menaces telles que l’ injection SQL, le cross-site scripting (XSS), l’injection de commandes, les bot malveillant, ou d’autres attaques web. Un WAF ajoute une couche de sécurité des applications qui analyse les requêtes HTTP et HTTPS, et peut détecter, bloquer ou consigner les activités malveillantes avant qu’elles n’atteignent les charges de travail protégées.

Selon l’architecture, un WAF peut fonctionner à la périphérie du réseau, aux côtés de l’infrastructure d’ingress Kubernetes, ou au sein même de l’environnement Kubernetes. La bonne approche dépend des applications d’une organisation, de l’architecture du trafic, des exigences en matière de performances, et du modèle de sécurité.

Comment fonctionne un WAF Kubernetes ?

Un WAF Kubernetes est un WAF qui protège les applications et les API déployées sur Kubernetes. Un WAF traditionnel se situe entre les utilisateurs et une application web, et analyse les requêtes entrantes à la recherche d’activités malveillantes. Le même principe s’applique à Kubernetes, mais l’environnement derrière le WAF peut être composé de nombreux conteneurs, pods, services, API et microservices qui peuvent changer et évoluer dynamiquement.

Une application Kubernetes peut avoir un chemin de requête semblable à celui-ci :

Utilisateur - Content Delivery Network/périphérie - WAF - passerelle ou ingress Kubernetes - Service - Pod

La position exacte du WAF varie. Certaines organisations déploient des logiciels de sécurité au sein de leurs groupes Kubernetes. D’autres inspectent le trafic avant qu’il n’atteigne le groupe à l’aide d’un WAF cloud ou en périphérie. Les approches hybrides peuvent utiliser plus d’un point d’application.

L’objectif est le même : identifier et arrêter le trafic d’application malveillant avant qu’il ne puisse exploiter ou perturber les charges de travail Kubernetes.

Flux du processus WAF Kubernetes
Un WAF Kubernetes examine les requête de couche d'application et applique une logique de sécurité avant de les autoriser à atteindre les charge de travail protégées.

Une requête typique peut suivre ces étapes :

Un utilisateur ou un client envoie une requête HTTP. La requête pourrait être destinée à un site web, une API ou un autre service exposé à Internet exécuté sur Kubernetes.
Le WAF inspecte la requête. Selon le déploiement, cela peut se produire en périphérie ou plus près de la charge de travail Kubernetes.
Le WAF analyse les informations de la couche d'application. Il peut inspecter des éléments tels que les URL, les paramètres, les en-têtes, les cookies, les corps de requête et les charges utiles d’API.
Les règles de sécurité et les mécanismes de détection évaluent le trafic. Le système détermine si la requête semble légitime, suspecte ou malveillante.
Une action est effectuée. Le WAF peut autoriser la requête, la bloquer, la consigner dans le Log, ou appliquer une autre réponse configurée.
Le trafic autorisé continue vers Kubernetes. La requête peut ensuite passer par le Load Balancer, le contrôleur d’ingress, ou la passerelle approprié, vers le service Kubernetes et, finalement, le pod concerné.

Les WAF modernes peuvent compléter les signatures d’attaque par une analyse comportementale, des renseignements sur les menaces, la limitation du débit, la Détection de bot, ou d’autres signaux de sécurité.

Pourquoi les environnements Kubernetes ont-ils besoin d’un WAF ?

Kubernetes fournit des capacités importantes d’infrastructure et d’orchestration, mais il ne remplace pas la sécurité de la couche d’application. Voici les raisons pour lesquelles un WAF est nécessaire dans un environnement Kubernetes :

Les applications Kubernetes restent des applications web
Le fait de déplacer une application dans des conteneurs n’élimine pas les vulnérabilités de son code. Une application hébergée sur Kubernetes peut toujours être exposée à l’ injection SQL, au XSS, à l’injection de commandes, à la traversée de chemin, aux attaques d’authentification, aux abus d’API, et à d’autres menaces web.

Kubernetes favorise les architectures distribuées
Kubernetes est couramment utilisé pour les microservices et les applications pilotées par API. Cela peut créer de nombreux points de terminaison d’application avec différentes fonctions, exigences d’accès aux données, et profils de risque. Les API deviennent par conséquent un élément important de la surface d’attaque.

Les environnements Kubernetes changent rapidement
Les pods peuvent être créés, détruits, et replanifiés automatiquement. Les applications peuvent également être mises à jour plusieurs fois par jour via des pipelines CI/CD. L’architecture de sécurité doit fonctionner avec ce modèle dynamique plutôt que de dépendre d’hypothèses d’infrastructure statiques.

Les charges de travail exposées à Internet sont continuellement ciblées
Les applications publiques et les API peuvent recevoir des analyses de vulnérabilités, des tentatives d’exploitation, des attaques d’identifiants, des bots malveillants, et du trafic de déni de service distribué, que le back-end s’exécute sur Kubernetes, des machines virtuelles, ou des serveurs physiques.

Comment un WAF aide
La sécurité Kubernetes comprend plusieurs préoccupations distinctes. La configuration du groupe, la gestion des secrets, les politiques de réseau, la gestion des identités et des accès, la sécurité des conteneurs, l’analyse des images, la sécurité de la durée d’exécution et la protection WAF résolvent différents problèmes.

Un WAF aide spécifiquement à protéger la couche d'application. Il ne doit pas être considéré comme un remplacement de la sécurisation de la plateforme Kubernetes elle-même.

Contre quelles menaces un WAF Kubernetes peut-il aider à protéger ?

Selon le WAF, la protection de la couche d’application peut traiter des attaque, notamment :

Injection SQL
Scripts intersites
Injection de commande
Traversée de chemin
Requêtes HTTP malveillantes
Exploitation de vulnérabilités connues
Attaques d’API
Analyse et sondage des applications

Lorsqu’elles sont intégrées à des technologies complémentaires, les organisations peuvent également se prémunir contre les bot malveillant, les attaque d’identifiants, le déni de service distribué de couche d'application, le scraping, et d’autres formes d’abus automatisés.

Le Top 10 de l’OWASP est une référence utile pour comprendre les principales catégories de risques de sécurité des applications web. Cependant, il ne faut pas s’attendre à ce qu’un WAF élimine tous les risques Open Web Application Security Project (OWASP), car certaines vulnérabilités concernent la conception de l’application, l’autorisation, la configuration, ou la logique métier, et doivent être corrigées dans l’application elle-même.

Quelles sont les bonnes pratiques pour déployer un WAF avec Kubernetes ?

Un WAF est plus efficace lorsqu’il s’inscrit dans une stratégie plus large de Kubernetes et de sécurité des applications.

1. Protéger les applications avant que le trafic n’atteigne le groupe lorsque cela est possible
Un WAF déployé en périphérie peut identifier les requêtes malveillantes avant qu’elles ne consomment les ressources réseau, d’ingress, de calcul et d’application de Kubernetes. La réduction du trafic indésirable en amont peut améliorer à la fois la sécurité, et l’efficacité de l’infrastructure.

2. Protéger les API ainsi que les pages web
Les environnements Kubernetes hébergent fréquemment des microservices pilotés par API. Inventoriez les API accessibles depuis l’extérieur et assurez-vous que les politiques de sécurité prennent en compte les points de terminaison d’API, plutôt que de protéger uniquement le trafic traditionnel des navigateurs.

3. Restreindre l’accès direct aux origines
Si une application est censée recevoir du trafic internet via une couche de sécurité en périphérie, les hacker ne devraient pas pouvoir contourner cette couche simplement en se connectant directement à une origine exposée. Lorsque l’architecture le permet, limitez l’accès à l’origine aux chemins de trafic autorisés.

4. Intégrer la sécurité dans CI/CD
Les déploiements Kubernetes sont souvent automatisés, la sécurité doit donc s’intégrer au même modèle opérationnel. L’infrastructure as code, les politiques sous contrôle de version, les tests de sécurité automatisés, et les déploiements reproductibles peuvent réduire la dérive de configuration.

5. Commencez par la visibilité
Avant de bloquer le trafic de manière agressive, comprenez ce que le WAF détecte. Les modes de surveillance ou de journalisation peuvent aider les équipes à évaluer les faux positif potentiels, et à comprendre le comportement normal de l’application avant d’appliquer de nouvelles règles.

6. Maintenez des politiques de sécurité gérables
Davantage de règles ne produisent pas nécessairement une meilleure sécurité. Des politiques excessivement complexes peuvent devenir difficiles à maintenir, et peuvent créer des faux positifs. Donnez la priorité aux protections à forte valeur ajoutée, et examinez régulièrement les exceptions obsolètes.

7. Combinez WAF et Bot Protection
Une requête HTTP d’apparence valide peut tout de même être malveillante lorsqu’elle est automatisée des milliers de fois. Bot Management peut compléter un WAF en identifiant les automatisations malveillantes impliquées dans des activités telles que le bourrage d’identifiants, le scan, le scraping et l’abus d’application.

8. Protection contre les attaques DDoS
Un WAF ne doit pas être la seule défense contre les attaques par déni de service. Utilisez une protection DDoS appropriée au niveau du réseau et de la couche d’application afin que le trafic d’attaque puisse être atténué avant d’épuiser les ressources de Kubernetes ou de l’application.

9. Surveiller les événements de sécurité de manière centralisée
Intégrez la télémétrie de sécurité du WAF aux plateformes de journalisation, de gestion des informations et des événements de sécurité, et d’observabilité, le cas échéant. Les équipes de développement, d’Opérations, et de sécurité doivent pouvoir enquêter sur les attaques sans corréler manuellement les informations entre les pods individuels.

10. Corriger les vulnérabilités dans l’application
Un WAF ajoute une couche de défense importante, mais il ne remplace pas le développement sécurisé. Continuez à corriger les dépendances, à tester les applications, à corriger les configurations non sécurisées, à mettre en œuvre une autorisation forte, et à corriger le code vulnérable.

Un WAF doit-il s’exécuter à l’intérieur ou à l’extérieur de Kubernetes ?

Les deux approches sont possibles.

WAF dans Kubernetes
Un WAF ou un composant de sécurité peut fonctionner dans l’environnement Kubernetes ou à proximité, en s’intégrant potentiellement à l’infrastructure d’ingress ou aux services d’application. Cette approche peut offrir aux organisations une flexibilité de déploiement et des contrôles de sécurité au plus près des charges de travail individuelles.

Cependant, l’infrastructure de sécurité au sein du groupe peut consommer des ressources du groupe, et peut devoir évoluer parallèlement au trafic d’attaque.

WAF en dehors de Kubernetes
Un WAF externe ou en périphérie inspecte les requêtes avant qu’elles n’atteignent Kubernetes. Cela peut empêcher les requête malveillantes de consommer les ressources d’ingress, de réseau, de calcul, et d’application à l’intérieur du groupe. Elle dissocie également la couche d’application de la sécurité de l’infrastructure qu’elle protège.

Déploiement hybride
Certaines organisations combinent la sécurité en périphérie avec des contrôles plus proches des charges de travail. Le modèle approprié dépend de l’architecture de l’organisation, des exigences de conformité, des pratiques opérationnelles, des applications, et du modèle de menace.

Qui a besoin d’un WAF Kubernetes ?

Les organisations devraient envisager une protection WAF lorsque leurs environnements Kubernetes hébergent des applications web ou des API exposées à Internet.

Fournisseurs Logiciel en tant que service
Les applications Logiciel en tant que service exposent couramment des systèmes de connexion, des API, des tableaux de bord, et des fonctionnalités destinées aux clients que les hackers peuvent cibler.

Entreprises d’e-commerce
Les boutiques en ligne, systèmes de paiement, fonctions de recherche, et API hébergés sur Kubernetes peuvent faire face à des tentatives d’injection, des bots malveillants, des attaques de compte, et des menaces DDoS.

Services financiers
Les applications qui traitent des informations financières ou des transactions peuvent bénéficier d’une sécurité des applications multicouche, ainsi que d’une authentification, d’une autorisation, d’un chiffrement, et d’un développement sécurisé robustes.

Entreprises des médias et de l’édition
Les plateformes de contenu à fort trafic peuvent faire face à des analyses de vulnérabilités, du scraping, des abus automatisés, et des pics de trafic soudains.

Entreprises axées sur les API
Les organisations exploitant un grand nombre d’API publiques ont besoin de contrôle capables de protéger les points de terminaison de l’application sans dépendre exclusivement de la sécurité réseau traditionnelle.

Les entreprises qui adoptent les microservice
À mesure que les organisations décomposent des application monolithiques en service distribués, le nombre d’API et d’interfaces d’application peut augmenter considérablement. Un WAF peut fournir une couche de sécurité supplémentaire au point où ces applications sont exposées à un trafic non fiable.

La sécurité de Kubernetes est-elle la même que la sécurité des applications ?

Non. La sécurité de Kubernetes englobe l’environnement sous-jacent d’orchestration des conteneurs, y compris des domaines tels que :

Accès au groupe
RBAC
Secrets
Politiques réseau
Images de conteneur
Sécurité des pods
Sécurité des nœuds
Sécurité de durée d’exécution
Sécurité de la chaîne d’approvisionnement

La sécurité des applications se concentre sur le logiciel exécuté sur cette infrastructure, y compris son code, ses API, l’authentification, l’autorisation et le traitement des entrées utilisateur. Un WAF traite principalement les menaces de la couche d'application. Les organisations qui exécutent Kubernetes doivent donc sécuriser à la fois la plateforme et les applications qui y fonctionnent.

Un WAF Kubernetes suffit-il à protéger les API ?

Réponse courte : non. Un WAF constitue une couche importante, mais une sécurité des API complète nécessite généralement des contrôle supplémentaires.

Les organisations devraient également prendre en compte :

Authentification forte et autorisation
Découverte et inventaire des API
Validation du schéma et des entrées
Limitation du débit
Bot Protection
Atténuation des attaques par déni de service distribué
Développement d’API sécurisé
Journalisation et surveillance
Protection appropriée contre les abus de logique métier

L’objectif est d’empêcher à la fois les exploits web traditionnels et les attaques qui abusent de fonctionnalités d’API par ailleurs légitimes.

Comment Fastly complète-t-il les environnements Kubernetes ?

Fastly peut protéger les applications hébergées sur Kubernetes sans exiger que le point d’application principal de la sécurité réside dans chaque groupe Kubernetes. Une architecture typique peut placer la plateforme Edge Cloud de Fastly devant les applications hébergées sur Kubernetes :

Utilisateurs - Fastly périphérie - Kubernetes infrastructure - Charges de travail des applications

Le trafic entrant de l’application atteint d’abord Fastly, où des contrôles de distribution et de sécurité peuvent être appliqués avant que les requêtes autorisées ne poursuivent vers l’environnement Kubernetes. Cette architecture peut aider les organisations à éloigner le trafic malveillant ou inutile de l’infrastructure Kubernetes, tout en fournissant une couche de sécurité cohérente sur l’ensemble des groupes et des environnements d’application.

Comment Fastly Next-Gen WAF fonctionne-t-il avec Kubernetes ?

Fastly Next-Gen WAF peut protéger les applications web et les API hébergées sur Kubernetes. Il prend en charge plusieurs modèles de déploiement, y compris des déploiements de WAF cloud à la périphérie de Fastly, ainsi que des options de déploiement plus proches de l’infrastructure des applications. Cela offre aux organisations une certaine flexibilité pour déterminer où l’inspection de la sécurité des applications a lieu.

Le WAF de Fastly utilise la technologie SmartParse pour analyser les paramètres de requête et identifier les comportements malveillants de l’application. Plutôt que de dépendre exclusivement de règles traditionnelles basées sur des expressions régulières, SmartParse est conçu pour identifier l’intention derrière les requêtes, et réduire les faux positifs.

Pour les applications Kubernetes, cela peut fournir une protection contre des classes d’attaque telles que :

Injection SQL
Scripts intersites
Injection de commande
Traversée de chemin
Autres attaques de la couche d’application

Le déploiement en périphérie peut également réduire la quantité de trafic malveillant atteignant les groupes Kubernetes dès le départ.

Fastly peut-il protéger plusieurs groupes Kubernetes ?

Oui. Une architecture de sécurité basée sur la périphérie peut être utile lorsque les applications s’étendent sur plusieurs groupes, régions, ou fournisseurs d’infrastructure. Au lieu d’exiger une pile de sécurité entièrement distincte exposée à Internet pour chaque groupe, le trafic peut passer par Fastly avant d’être acheminé vers l’origine application appropriée.

Cela peut être utile pour les organisations opérant :

Plusieurs groupes Kubernetes
Déploiements multirégion
Applications de cloud hybride
Architectures multicloud
Kubernetes aux côtés d’une infrastructure non-Kubernetes

La configuration précise dépendra de l’architecture réseau et d’origine de l’application.

Quelles autres capacités de sécurité Fastly complètent la protection WAF de Kubernetes ?

La protection WAF fait partie du portefeuille plus large de sécurité des applications de Fastly.

Fastly Bot Management
Fastly Bot Management aide à identifier et à contrôler le trafic automatisé. Cela peut compléter la protection WAF contre les bots impliqués dans l’analyse des vulnérabilités, les attaques d’identifiants, le scraping, et les abus d’application.

Protection DDoS Fastly
Protection DDoS Fastly aide à défendre les application contre les attaque conçues pour submerger les ressources du réseau ou des application. L’atténuation des attaque en périphérie peut empêcher de grands volumes de trafic indésirable d’atteindre l’infrastructure Kubernetes.

Limitation du débit
Limitation du débit peut aider à protéger les points de terminaison d’application sensibles et coûteux en calcul. Pour les applications Kubernetes, cela peut être particulièrement utile pour les API, les points de terminaison d’authentification, les fonctions de recherche, et d’autres services où des requêtes excessives pourraient consommer des ressources back-end.

Content Delivery Network et cache
Le CDN de Fastly peut mettre en cache le contenu éligible en périphérie, réduisant les requêtes qui doivent atteindre les charges de travail Kubernetes. Cela peut améliorer les performances de l’application, tout en réduisant la demande sur les contrôleurs d’entrée, les services, les pods, les bases de données, et les autres infrastructures d’origine.

Visibilité en temps réel
Fastly fournit des capacités de journalisation en temps réel et d’observabilité qui peuvent aider les équipes de sécurité et d’Opérations à comprendre les schémas de trafic et à enquêter sur les activités malveillantes. Cela peut compléter l’observabilité native de Kubernetes en fournissant une visibilité sur le trafic avant qu’il n’atteigne le groupe.