~10 minutes
Cet article fait partie de la série OWASP Top 10 Kubernetes 2026. Retrouvez le tableau de bord complet des dix risques et la matrice STRIDE sur la page d’entrée de la série.
K07 se distingue de K03 sur un point précis : K03 traite le réseau interne au cluster, le mouvement latéral entre pods et namespaces. K07 traite ce qui est exposé vers l’extérieur ; la couche infrastructure réseau, les services qui sortent du cluster vers des plages d’adresses plus larges, et les configurations TLS qui donnent l’illusion du chiffrement sans en fournir les garanties.
Dans beaucoup de clusters, cette frontière est floue. Un Service de type LoadBalancer crée une IP externe sur le cloud provider en une ligne de YAML. Sans gouvernance, cette IP est exposée avant même que l’équipe sécurité en soit informée.
On va distinguer deux catégories dans K07 :
- les expositions non intentionnelles (quelqu’un a créé un LoadBalancer pour tester et oublié de le supprimer)
- et les expositions mal sécurisées (le service est là pour une bonne raison, mais sans TLS, sans authentification, sans contrôle d’accès IP).
Note du PandaRedacteur ; Les deux arrivent en production et peuvent se découvrir lors d’un audit (plus ou moins simple)
Vecteurs d’attaque
L’ouverture permanente
Commencons par celui-là parce qu’il représente une bonne majorité des incidents sur ce sujet.
Un développeur crée un Service de type LoadBalancer pour tester rapidement un endpoint depuis son poste. Le test fonctionne. Le développeur passe à autre chose. Le LoadBalancer reste, avec son IP publique provisionnée par le cloud provider, accessible depuis Internet.
Sur AWS, GCP, Azure : la création d’un Service LoadBalancer approvisionne une IP publique ou une IP interne selon la configuration. Si le sous-réseau n’est pas explicitement restreint, l’IP publique est souvent le défaut. Et sans SecurityGroup ou firewall rule restrictif, l’endpoint est accessible par n’importe qui.
La détection est banale pour un attaquant qui scanne les plages d’adresses du cloud provider(via nmap ou nuclei). La corrélation entre une IP AWS/GCP/Azure et un endpoint Kubernetes non authentifié prend quelques secondes.
Le trou dans le firewall/WAF
Les NodePort exposent un port sur chaque node du cluster, dans la plage 30000-32767 par défaut. C’est pratique pour les environnements de développement. En production, ça ouvre un port sur chaque node, et si le firewall du cloud provider n’est pas correctement restreint, ce port est accessible depuis l’extérieur.
Le scénario de base: un service de debug ou un outil de monitoring interne déployé avec un NodePort pour faciliter l’accès pendant une intervention. Le firewall n’a pas été mis à jour pour bloquer la plage 30000-32767. Le service reste exposé après la fin de l’intervention.
C’est le genre de chose qu’on trouve dans les audits de clusters cloud quand on scanne les nodes directement et pas seulement l’API Server.
TLS absent ou auto-signé sans contrôle
Un Ingress ou une HTTPRoute Gateway sans TLS expose le trafic applicatif en clair. Moins évident : un TLS avec un certificat auto-signé non contrôlé n’est guère mieux dans un contexte où les clients ne vérifient pas la chaîne de confiance.
Quelques cas courants d’expérience :
- Ingress en HTTP sur des endpoints “internes” accessibles depuis le réseau d’entreprise, avec des données sensibles qui transitent en clair
- Certificats auto-signés acceptés par les clients via
insecureSkipVerify: true, rendant le TLS purement cosmétique - Certificats expirés non remplacés, provoquant des erreurs qui poussent les équipes à désactiver la vérification en urgence
Note du PandaRedacteur ; La rotation des certificats est le point de défaillance le plus fréquent sur TLS. J’ai vu des équipes très sérieuses tomber dans ce piège : un cert-manager mal configuré, une alarme d’expiration non reçue, et une nuit de panique à relancer des services en production.
Mitigations 2026
Inventaire et gouvernance des expositions
La première mitigation n’est pas un outil : c’est savoir ce qui est exposé. kubectl get svc -A | grep -E 'LoadBalancer|NodePort' est le point de départ. Sur un cluster cloud, la liste des LoadBalancers correspond à des IP provisionnées et facturées par le provider ; c’est souvent un levier pour motiver l’inventaire.
Kyverno peut imposer des annotations obligatoires sur les services de type LoadBalancer (owner, expiration, justification), et alerter ou bloquer la création sans annotation. Ce n’est pas du contrôle d’accès réseau, mais ça donne une traçabilité.
Pour les clusters cloud, les Security Groups ou les firewall rules doivent restreindre les plages NodePort. Le par défaut le plus courant autorise tout le trafic entrant sur 0.0.0.0/0.
Gateway API et TLS automatique avec cert-manager
Gateway API remplace progressivement l’Ingress sur les nouvelles installations.
Elle apporte une séparation claire des responsabilités : l’équipe infrastructure contrôle la GatewayClass et la Gateway, les équipes applicatives gèrent les HTTPRoute. Les erreurs de configuration TLS au niveau applicatif ne peuvent plus affecter la Gateway de production si les rôles sont bien séparés.
cert-manager reste un standard pour la gestion des certificats dans Kubernetes : émission automatique depuis Let’s Encrypt ou une PKI interne, rotation avant expiration, alertes sur les certificats qui approchent de l’expiration. L’activer n’est pas complexe ; ne pas l’activer expose à la rotation manuelle et aux panics nocturnes.
Une annotation sur l’Ingress ou la HTTPRoute. Le certificat est provisionné, renouvelé et remplacé automatiquement.
mTLS pour les communications internes sensibles
Pour les services qui se parlent à l’intérieur du cluster et dont les communications portent des données sensibles, le mTLS via un service mesh (Istio, Linkerd, Cilium) garantit que même sur le réseau interne, les communications sont chiffrées et authentifiées mutuellement.
Maintenant, est-ce vraiment nécessaire ? Il faut se poser comme d’habitude les bonnes questions avec une approche de risques (STRIDE, PASTA ou au doigt mouillé pour certains…), mais si vous pouvez allez-y, le Zero Trust vous en remerciera.
Nécessaire pour les flux qui portent des données sensibles, des credentials ou des instructions d’administration.
Note du PandaRedacteur ; La décision mérite une classification explicite et donc une gouvernance des données associées.
DevSecOps : intégrer K07 dans la chaîne CI/CD
Ce contenu représente de nombreuses heures de travail, d'expérience etc... J'ai remarqué que mon contenu était repris par certaines sociétés/personnes et j'ai donc décidé de donner du contenu minimal sur ce blog. C'est pourquoi je vous invite a me contacter sur LinkedIn en mentionnant cet article pour plus d'informations.
- ✓ Inventorier les LoadBalancers et NodePorts régulièrement : ce qui est exposé doit être connu, justifié et tracé.
- ✓ Gateway API + cert-manager : TLS automatique, rotation sans intervention manuelle, séparation des responsabilités infra/applicatif.
- ✓ Les Security Groups cloud ne sont pas automatiques : les plages NodePort doivent être explicitement restreintes sur les cloud providers.
- ✓ Un certificat auto-signé non contrôlé est une fausse sécurité : si les clients font
insecureSkipVerify, TLS ne sert à rien. - ✓ cert-manager élimine les panics nocturnes liés aux certificats expirés : la rotation manuelle est une source de risque opérationnel évitable.