NetworkPolicy (Kubernetes)

Une NetworkPolicy est la ressource Kubernetes qui restreint les flux réseau entre pods. Elle joue le rôle d’un pare-feu interne au cluster : elle sélectionne des pods par labels et déclare quels trafics entrants (ingress) et sortants (egress) leur sont permis, en fonction de la source ou de la destination — d’autres pods, des namespaces, ou des plages d’adresses IP.

Le point que tout le monde découvre trop tard

Par défaut, Kubernetes n’isole rien : n’importe quel pod peut parler à n’importe quel autre pod du cluster, tous namespaces confondus. Un cluster sans NetworkPolicy est un réseau à plat où la compromission d’une seule application expose tout le reste. Les politiques ne s’activent que par sélection : dès qu’une NetworkPolicy sélectionne un pod, tout le trafic non explicitement autorisé vers ce pod (ou depuis lui, pour l’egress) est refusé. Un pod que rien ne sélectionne reste, lui, entièrement ouvert.

Le modèle deny-all

L’approche standard consiste à poser dans chaque namespace une politique qui sélectionne tous les pods (podSelector: {}) sans rien autoriser — le deny-all — puis à ouvrir flux par flux : le frontend vers l’API, l’API vers la base, tout le monde vers le DNS du cluster. Ce dernier point est le piège récurrent : un deny-all en egress qui oublie d’autoriser le port 53 vers CoreDNS casse la résolution de noms, et les symptômes (timeouts diffus) n’évoquent pas immédiatement une règle réseau. Les politiques sont additives : plusieurs NetworkPolicies peuvent sélectionner le même pod, et l’union de leurs autorisations s’applique. Il n’existe pas de règle « interdire » qui primerait sur une autorisation.

Prérequis et limites

Les NetworkPolicies ne sont pas appliquées par Kubernetes lui-même mais par le plugin réseau (CNI) : Calico ou Cilium les implémentent, d’autres les ignorent silencieusement. C’est le piège le plus sournois — une politique acceptée par l’API sans erreur peut n’avoir strictement aucun effet. Le standard couvre les couches 3 et 4 (adresses, ports, protocoles) : filtrer par méthode HTTP ou par identité applicative relève d’extensions propres à chaque CNI ou d’un service mesh. Enfin, une NetworkPolicy protège les flux entre pods, pas l’accès au cluster depuis l’extérieur, qui reste l’affaire de l’Ingress et du pare-feu d’infrastructure.