Introduction aux NetworkPolicies : Pare-feu au niveau des Pods

Définir des barrières : le rôle des Network Policies

Face au modèle réseau par défaut ouvert de Kubernetes, qui autorise toutes les communications inter-Pods, il est devenu indispensable de disposer d'un mécanisme pour restreindre et contrôler ces flux. C'est ici qu'interviennent les Network Policies (ou Politiques Réseau). Elles constituent la réponse native de Kubernetes pour implémenter une segmentation réseau et appliquer des règles de pare-feu directement au niveau des Pods.

Considérez une Network Policy comme un ensemble de règles de sécurité définissant quel trafic réseau est autorisé vers et depuis un groupe spécifique de Pods. Au lieu d'un grand espace ouvert où tout le monde communique librement, les Network Policies permettent de construire des 'murs' virtuels autour de vos applications ou de leurs composants, n'ouvrant que les 'portes' strictement nécessaires.

L'objectif principal est d'adopter une approche de sécurité par défaut restrictif (default deny). Dès qu'une Network Policy cible un Pod, celui-ci n'acceptera (ou n'émettra) que le trafic explicitement autorisé par cette politique ou d'autres politiques applicables. Tout autre trafic sera bloqué, réduisant drastiquement la surface d'attaque et limitant les possibilités de mouvement latéral en cas de compromission.

L'objet Kubernetes `NetworkPolicy`

Techniquement, une Network Policy est une ressource standard de l'API Kubernetes, définie dans un fichier manifeste YAML, tout comme les Pods, Deployments ou Services. Cet objet `NetworkPolicy` contient les spécifications qui décrivent comment le trafic doit être contrôlé.

Les éléments clés d'une définition de Network Policy sont :

• podSelector : Identifie le groupe de Pods auquel la politique s'applique, en se basant sur leurs labels. Si omis, la politique s'applique à tous les Pods du namespace.
• policyTypes : Spécifie si la politique contient des règles pour le trafic entrant (Ingress), sortant (Egress), ou les deux. Si omis, mais que des règles `ingress` ou `egress` sont définies, les types correspondants sont activés. Si `policyTypes` est présent mais vide, ou si aucune règle n'est définie, cela crée une politique d'isolation par défaut (tout refuser).
• ingress : Une liste de règles définissant le trafic entrant autorisé vers les Pods sélectionnés.
• egress : Une liste de règles définissant le trafic sortant autorisé depuis les Pods sélectionnés.

Ces politiques opèrent principalement aux couches 3 (IP) et 4 (TCP, UDP, SCTP) du modèle OSI. Elles permettent de filtrer le trafic en fonction des adresses IP sources/destinations (souvent représentées par des sélecteurs de Pods ou de namespaces) et des ports.

Implémentation et dépendance au CNI

Il est fondamental de comprendre que la définition d'une ressource `NetworkPolicy` dans l'API Kubernetes ne suffit pas à elle seule. L'application réelle de ces règles est déléguée au plugin réseau CNI (Container Network Interface) installé dans le cluster.

Le CNI est le composant qui gère l'attribution des adresses IP aux Pods et la configuration du routage réseau au sein du cluster. Pour que les Network Policies soient effectives, le CNI choisi doit supporter cette fonctionnalité et être capable d'interpréter les objets `NetworkPolicy` pour configurer les règles de pare-feu appropriées au niveau de l'infrastructure réseau (souvent via iptables, eBPF, ou d'autres mécanismes).

Des CNI populaires comme Calico, Cilium, Weave Net, Antrea, et d'autres implémentent le support des Network Policies. Si vous utilisez un CNI qui ne les supporte pas, les objets `NetworkPolicy` que vous créerez seront simplement ignorés, et le trafic restera ouvert par défaut. Vérifiez donc toujours la documentation de votre CNI pour confirmer sa compatibilité.