Politiques réseau Kubernetes : erreurs fréquentes et modèles fiables de segmentation du trafic

Les NetworkPolicy de Kubernetes sont l’un de ces mécanismes qui semblent simples jusqu’au moment où l’on tente de les appliquer dans un cluster très sollicité. En 2026, elles restent un élément central d’une approche réseau fondée sur le moindre privilège, mais elles sont faciles à mal configurer : l’application dépend du CNI, les sélecteurs reposent sur les labels, et « ce que l’on voulait dire » n’est pas toujours « ce que fait l’API ». Ce guide se concentre sur les erreurs qui provoquent réellement des incidents et sur les modèles que les équipes réutilisent pour segmenter le trafic sans casser la production.

Comprendre ce que NetworkPolicy applique vraiment (et ce qu’elle n’applique pas)

Le cas le plus courant du « ça ne marche pas » n’est pas un problème de YAML : NetworkPolicy est une API, pas un pare-feu en soi. Le cluster doit utiliser une solution réseau qui met effectivement en œuvre les NetworkPolicy ; sinon, les règles peuvent exister sans produire le moindre effet. Même lorsque l’application est activée, le comportement peut varier selon le CNI pour certains cas limites, la journalisation et l’observabilité ; il faut donc considérer le « support » comme quelque chose à vérifier, pas à supposer.

Ensuite, il faut être précis sur la notion d’isolement. Par défaut, les pods ne sont pas isolés et acceptent du trafic depuis n’importe où. Un pod devient isolé pour l’entrée et/ou la sortie uniquement lorsqu’il est sélectionné par une policy qui couvre cette direction (via policyTypes ou un comportement implicite). À partir de là, les règles fonctionnent comme des listes d’autorisation : le trafic n’est autorisé que si au moins une policy applicable l’autorise, et tout le reste est refusé pour la direction isolée.

Enfin, gardez en tête la couche à laquelle opère Kubernetes NetworkPolicy. La NetworkPolicy « classique » se situe surtout en L3/L4 : blocs IP, namespaces, pods et ports. Si votre exigence de segmentation ressemble plutôt à « autoriser uniquement ce chemin HTTP » ou « uniquement ce nom DNS », il peut être nécessaire d’utiliser des extensions propres au CNI ou des API de policy plus récentes, au lieu de forcer ces besoins dans une NetworkPolicy de base.

Erreurs typiques à ce sujet

S’appuyer sur une policy dans un cluster où l’application n’est pas activée (ou pas activée sur tous les pools de nœuds) reste l’erreur numéro un. Le YAML semble correct, la CI passe, rien ne change, et l’équipe ne s’en rend compte qu’au moment d’un audit sécurité ou d’un incident. Ajoutez un contrôle explicite dans vos procédures : confirmer quel CNI applique les policies et comment valider l’application dans un namespace hors production.

Laisser policyTypes implicite et supposer que cela couvre les deux directions crée des failles discrètes. Les équipes écrivent souvent une policy d’ingress et pensent qu’elle limite aussi les sorties ; puis découvrent que l’egress est resté totalement ouvert. Rendez la direction explicite pour tout workload où les sorties comptent (c’est le cas de la plupart).

Penser que les objets Service sont des « cibles » de policy est un autre malentendu récurrent. NetworkPolicy sélectionne des pods, pas des Services. On peut concevoir des rules qui correspondent aux pods derrière un Service, mais le nom du Service n’est pas un sélecteur. Quand on « autorise le Service », on oublie souvent le jeu de labels des pods, et la règle ne correspond à rien.

Construire la segmentation autour de frontières stables : namespaces, labels et services partagés

Un schéma de segmentation qui résiste aux changements organisationnels s’appuie sur des frontières qui ont un sens : les namespaces pour la multi-tenance et le cycle de vie, les labels pour l’identité et le rôle des applications, et une liste courte de services partagés (DNS, logs, métriques, ingress, passerelles de mesh) que beaucoup de workloads doivent joindre. Si ces fondamentaux sont incohérents, les NetworkPolicies deviennent fragiles, et les équipes finissent par les désactiver ou par ajouter des exceptions trop larges qui annulent l’objectif.

Un modèle pragmatique consiste à standardiser un contrat minimal de labels : app.kubernetes.io/name, app.kubernetes.io/part-of, app.kubernetes.io/component, ainsi qu’un label d’environnement ou de tenant au niveau du namespace. Les sélecteurs deviennent alors lisibles et prévisibles, et vous réduisez le temps de diagnostic lié aux labels improvisés.

Les services partagés méritent un traitement particulier. Le DNS est la panne la plus fréquente lors d’un déploiement de policies : une équipe active un egress en refus par défaut, puis oublie d’autoriser les sorties vers les pods DNS (et parfois vers l’adresse DNS locale au nœud si elle est utilisée). Considérez le DNS, la synchronisation horaire (si applicable) et les proxys egress obligatoires comme des dépendances de base et modélisez-les explicitement dans votre modèle de référence.

Modèles fonctionnels que les équipes réutilisent sans cesse

Modèle 1 : « Base par namespace + ajustements par application ». Démarrez avec un refus par défaut au niveau du namespace pour l’ingress (et l’egress si nécessaire), puis ajoutez de petites rules d’autorisation propres à chaque application. L’objectif n’est pas d’écrire une matrice parfaite dès le premier jour, mais de créer un périmètre contrôlé et d’itérer de manière sûre au fil de la découverte des flux légitimes.

Modèle 2 : « Liste d’autorisation pour les services partagés ». Maintenez un petit ensemble de policies (souvent gérées par l’équipe plateforme/SRE) qui autorisent tous les namespaces applicatifs à joindre les services essentiels : DNS, backends des contrôleurs d’ingress (si nécessaire), agents d’observabilité, et endpoints d’admission/webhook indispensables au fonctionnement du cluster. Gardez cette liste courte et révisée : chaque exception « partagée » peut devenir un raccourci de mouvement latéral si elle s’étend.

Modèle 3 : « Niveaux basés sur les labels dans un namespace ». Pour les équipes qui préfèrent moins de namespaces, utilisez des niveaux comme role=frontend, role=backend, role=db, puis définissez les flux autorisés : frontend → backend, backend → db, et refusez le reste. Cela correspond à la façon dont on conçoit l’architecture applicative et limite la prolifération de policies par rapport à des sélecteurs ponctuels.

Déploiement et diagnostic : éviter les pannes et prouver ce qui a changé

En 2026, la stratégie la plus sûre reste un déploiement progressif. Vous commencez par documenter les flux attendus (un tableau simple suffit), puis vous introduisez un refus par défaut sur un périmètre contrôlé et vous ajoutez des règles d’autorisation de façon itérative tout en surveillant. L’approche « big bang » — activer le refus par défaut partout et corriger en direct — finit presque toujours en incident bruyant puis en retour arrière.

Les tests doivent inclure des cas positifs et négatifs. Vérifier que « le service A peut appeler le service B » ne suffit pas : il faut aussi un test de non-régression indiquant que « le service C ne peut pas appeler le service B ». Sans tests négatifs, les policies dérivent souvent vers le permissif avec le temps, parce que personne ne voit les chemins supplémentaires qui se sont ouverts.

Le diagnostic a besoin d’une méthode constante. Commencez par confirmer si le pod est sélectionné par une policy (et pour quelle direction), puis listez toutes les policies du namespace susceptibles de correspondre, et seulement ensuite inspectez les rules. Si votre CNI fournit une visibilité des flux ou des logs de verdict, utilisez-les tôt : ils réduisent souvent le diagnostic de plusieurs heures à quelques minutes en montrant quelle règle a autorisé ou refusé une connexion.

Pièges fréquents en 2026 et façons de les gérer

L’egress est l’endroit où la plupart des difficultés apparaissent : API externes, dépôts de paquets, fournisseurs d’identité et webhooks transforment vite le « refus par défaut » en longue liste d’autorisations. Deux atténuations aident : faire passer les sorties par un chemin egress contrôlé (proxy ou passerelle) et autoriser principalement ce chemin contrôlé plutôt que des dizaines de destinations externes. Les policies restent plus petites et les audits plus simples.

Les sélecteurs de namespace échouent en pratique quand les namespaces ne sont pas étiquetés de manière cohérente. On écrit des rules basées sur namespaceSelector, puis on découvre que des namespaces système ou hérités n’ont pas de labels, et la règle ne peut pas les matcher. La correction est autant organisationnelle que technique : définir un standard minimal de labels de namespace et l’appliquer (des contrôles de type policy-as-code sont très efficaces).

Enfin, gardez un œil sur l’écosystème autour de NetworkPolicy. Le groupe de travail upstream sur l’API de policy réseau continue de faire évoluer des ressources de policy globales, orientées administrateurs, sous forme de CRD (avec des changements de nommage et de version au fil du temps). Si vous avez besoin de garde-fous globaux ou de baselines entre namespaces, évaluez ces API de niveau admin dans votre environnement plutôt que d’essayer d’approximer une « policy de cluster » uniquement avec des objets NetworkPolicy par namespace.