Le 25 octobre 2023, le National Institute of Standards and Technology (NIST) a signalé trois vulnérabilités CVE affectant NGINX Ingress Controller for Kubernetes :
- CVE-2022-4886 – le nettoyage des chemins d’ingress-nginx peut être contourné à l’aide de la directive «
log_format». - CVE-2023-5043 – l’injection d’annotations dans ingress-nginx permet l’exécution de commandes arbitraires.
- CVE-2023-5044 – Une injection de code se produit via l’annotation nginx.ingress.kubernetes.io/permanent-redirect.
Ce rapport et les publications qui ont suivi (telles que « Urgent : de nouvelles failles de sécurité découvertes dans le contrôleur Ingress NGINX pour Kubernetes ») ont suscité une certaine confusion (ainsi que de nombreuses demandes d’assistance) quant aux contrôleurs Ingress NGINX réellement concernés et aux personnes devant se préoccuper de corriger les vulnérabilités décrites par ces CVE.
Cette confusion est tout à fait compréhensible : saviez-vous qu’il existe plusieurs contrôleurs Ingress basés sur NGINX ? Pour commencer, il existe deux projets totalement distincts portant le nom « NGINX Ingress Controller » :
- Projet communautaire – Disponible dans le dépôt kubernetes/ingress-nginx sur GitHub, ce contrôleur Ingress repose sur le plan de données NGINX Open Source, mais il est développé et maintenu par la communauté Kubernetes, et sa documentation est hébergée sur GitHub.
- Projet NGINX – Disponible dans le dépôt nginxinc/kubernetes-ingress sur GitHub, NGINX Ingress Controller est développé et maintenu par F5 NGINX, avec une documentation sur docs.nginx.com. Ce projet NGINX officiel est disponible en deux éditions :
- Basé sur NGINX Open Source (option gratuite et open source)
- Basé sur NGINX Plus (option commerciale)
Il existe également d’autres contrôleurs Ingress basés sur NGINX, tels que Kong. Heureusement, leurs noms permettent de les distinguer facilement. Si vous ne savez pas exactement lequel vous utilisez, vérifiez l’image de conteneur du contrôleur Ingress en cours d’exécution, puis comparez le nom de l’image Docker avec les dépôts répertoriés ci-dessus.
Les vulnérabilités (CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044) décrites ci-dessus s’appliquent uniquement au projet communautaire (kubernetes/ingress-nginx). Les projets NGINX pour NGINX Ingress Controller (nginxinc/kubernetes-ingress, qu’ils soient open source ou commerciaux) ne sont pas affectés par ces CVE.
Pour en savoir plus sur les différences entre NGINX Ingress Controller et les projets de contrôleurs Ingress, consultez notre article de blog « Guide pour choisir un contrôleur Ingress, 4e partie : les options de NGINX Ingress Controller ».
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.