Développement

Sécurité Kubernetes : Réagissez à la faille IngressNightmare

Matthieu

IngressNightmare : Une faille critique dans Kubernetes

La faille de sécurité IngressNightmare, découverte récemment, représente une menace sérieuse pour les clusters Kubernetes. Elle permet à un attaquant distant d'exécuter du code arbitraire au sein du cluster, avec des privilèges élevés. Cette vulnérabilité réside dans le contrôleur Ingress NGINX, un composant largement utilisé pour exposer les services Kubernetes au monde extérieur.

Impact et risques

Un attaquant exploitant cette faille peut :

  • Accéder à des informations sensibles stockées dans le cluster, telles que des clés d'API, des mots de passe et des certificats.
  • Manipuler les services Kubernetes, voire prendre le contrôle total du cluster.
  • Lancer des attaques contre d'autres systèmes connectés au réseau du cluster.

Correction et mise à jour

La correction de cette faille est disponible dans les versions 1.12.1 et 1.11.5 du contrôleur Ingress NGINX. Cependant, pour bénéficier pleinement des correctifs et des améliorations de sécurité, il est recommandé de mettre à jour le cluster Kubernetes vers la version 1.32 ou ultérieure.

Le défi de la migration du load balancer OVH

La mise à jour vers la version 1.32 de Kubernetes implique un défi supplémentaire pour les utilisateurs d'OVHcloud : la migration du load balancer. OVHcloud a en effet annoncé la fin de support de son ancien load balancer au profit d'une nouvelle solution basée sur Octavia.

Cette migration nécessite une adaptation de la configuration du cluster Kubernetes, notamment au niveau des annotations Ingress. Il est crucial de suivre attentivement la documentation d'OVHcloud pour effectuer cette migration en douceur et éviter toute interruption de service.

Personnellement ayant un petit cluster, disons de petite taille avec peu de service SaaS, j'ai décidé dee lancer l'opération avec une petite intéruption de service.

Et la manipulation fût je dois dire assez simple, j'ai tout simplement modifier l'annotation présente dans le service NGinx en remplaçant iolb par octavia comme vous pour le voir sur la capture suivante.

L'impact ? Et bien l'ancien Load balancer est décomissionné et un nouveau est provisionné automatiquement.

ATTENTION !! Qui dit nouveau load balancer, dit nouvelle IP externe pour votre cluster donc veillez à mettre à jour votre DNS si cela n'est pas gérer automatiquement.

Conclusion et note pour moi-même :

  • Planifier la mise à jour du cluster Kubernetes régulièrement.
  • Suivre les recommandations de sécurité de Kubernetes et d'OVHcloud pour protéger votre cluster contre les attaques.
  • Surveiller régulièrement les alertes de sécurité et les mises à jour des composants Kubernetes.