Les politiques réseau Kubernetes

Mise à jour : 27/03/2025

Comment s’assurer que seuls les pods autorisés peuvent communiquer entre eux dans un cluster Kubernetes ? Peut-on vraiment contrôler les flux réseau entre microservices ? Et que se passe-t-il si un pod malveillant tente d’accéder à un autre ? Ce sont des questions que je me suis posées en cherchant à sécuriser mes déploiements. La réponse se trouve dans les Network Policies, un outil puissant mais souvent sous-estimé. Explorons ensemble comment elles peuvent renforcer la sécurité de votre cluster.

Pourquoi utiliser les Network Policies en Kubernetes ?

Quand on parle de sécurité dans une architecture Kubernetes, on pense souvent à l’authentification, au chiffrement ou aux mises à jour des conteneurs. Mais il y a un principe fondamental que je considère essentiel : limiter les communications au strict nécessaire. C’est le fameux principe du least privilege appliqué au réseau. En gros, si un pod n’a pas besoin de parler à un autre pod, alors il ne devrait pas en avoir la possibilité.

Par défaut, Kubernetes est très permissif. Tous les pods peuvent se parler, quel que soit leur rôle, leur namespace ou leur niveau de sensibilité. Cela va à l’encontre des bonnes pratiques en matière d’architecture sécurisée. Un service exposé à l’extérieur pourrait, en cas de compromission, explorer tout votre réseau interne. Et ça, c’est exactement ce qu’on veut éviter.

C’est là qu’interviennent les Network Policies. Elles permettent de :

Définir qui peut accéder à un pod donné,
Restreindre les flux sortants vers l’extérieur,
Isoler les environnements de test, de staging et de production,
Limiter l’impact d’une faille en cloisonnant les services.

À mon avis, mettre en place des Network Policies, c’est comme poser les cloisons d’un immeuble : on empêche les incendies (ou les attaques) de se propager trop facilement. C’est une couche de sécurité réseau indispensable qui complète les autres mécanismes déjà en place.

Ce n’est pas toujours évident au début, mais une fois qu’on comprend la logique, on réalise que ces règles sont un outil redoutablement efficace pour renforcer la posture de sécurité d’un cluster.

Attention : toutes les CNI ne supportent pas les Network Policies

Avant de commencer à écrire des Network Policies, il y a une chose que j’ai apprise à mes dépens : toutes les solutions réseau (CNI) ne les prennent pas en charge. Et sans ce support, vos règles de sécurité ne seront tout simplement pas appliquées.

Kubernetes définit le concept de Network Policies, mais ne les applique pas lui-même. C’est le plugin CNI (Container Network Interface) qui doit implémenter cette fonctionnalité.

Certains plugins très utilisés supportent pleinement les Network Policies :

Calico
Cilium
Weave Net
Kube-router
Antrea
D’autres, comme Flannel (dans sa configuration par défaut), ne prennent pas en charge les Network Policies. Dans ce cas, vous pouvez écrire les règles YAML, mais elles n’auront aucun effet.

À retenir : avant d’implémenter des politiques réseau, assurez-vous que votre CNI les gère. Sinon, c’est comme poser une alarme factice sur une porte ouverte.

Concepts fondamentaux des Network Policies

Voici les éléments clés à comprendre pour bien utiliser les Network Policies dans Kubernetes :

PodSelector : permet de cibler les pods concernés par une policy. Il s’appuie sur les labels pour désigner les pods à protéger. Sans sélection, la policy ne s’applique à rien.
PolicyTypes : indique si la policy contrôle le trafic entrant (Ingress), sortant (Egress), ou les deux. Si ce champ est omis, Kubernetes déduit le type selon les règles présentes.
Ingress : concerne les connexions entrantes vers un pod. On l’utilise pour définir précisément qui peut initier une communication vers un service donné.
Egress : définit les flux sortants depuis un pod. Cela me permet de bloquer l’accès à Internet ou d’autoriser uniquement certains services internes.
from / to : désigne les sources ou destinations autorisées pour le trafic. Ces règles utilisent généralement :
- des podSelector (ex. : seuls les pods avec app: frontend peuvent accéder au backend),
- des namespaceSelector (ex. : autoriser tout le trafic depuis un namespace précis),
- des ipBlock (ex. : autoriser les connexions depuis une plage d’IP externe).
ports : permet de restreindre le trafic à certains ports ou protocoles. Sans cela, tous les ports sont autorisés par défaut dans les connexions valides.
Default deny : une fois une policy appliquée à un pod, tout le trafic est bloqué sauf celui explicitement autorisé. Cela peut surprendre la première fois, mais c’est la base d’une architecture réseau sécurisée.

Ces concepts permettent de construire des règles précises et efficaces. En les combinant, on peut cloisonner ses services, réduire la surface d’attaque, et mieux contrôler ce qui circule dans nos cluster Kubernetes.

Comment configurer une Network Policy dans Kubernetes

Créer une Network Policy, c’est comme écrire des règles de securité dans le cloud. La structure est claire, mais chaque ligne compte. Voici comment procéder, étape par étape :

Identifier le pod cible

Avant tout, repérez les pods que vous voulez protéger. On s’appuie sur leurs labels, car la policy s’applique via un podSelector. Par exemple, si votre pod a ce label :
```
labels:
  app: backend
```
Définir le type de trafic à contrôler

On choisit si on veut restreindre le trafic entrant (Ingress), le trafic sortant (Egress), ou les deux. Dans la majorité des cas, on commence par l’Ingress pour bloquer les accès non autorisés.

Écrire le manifeste YAML

Voici un exemple minimaliste que vous pouvez utiliser pour autoriser uniquement les pods frontend à contacter les pods du backend sur le port 8080 :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Appliquer la policy

Une fois le fichier prêt, on l’applique avec :
Terminal window
```
kubectl apply -f allow-frontend-to-backend.yaml
```
Vérifier le comportement

Après déploiement, on fait des tests simples entre pods pour m’assurer que le trafic est bien autorisé ou bloqué selon les règles définies. Par exemple :
Terminal window
```
kubectl exec -it pod-frontend -- curl backend:8080
```

Ajouter une règle par défaut “deny all” (optionnel, mais recommandé)

Pour s’assurer qu’aucun autre pod ne puisse accéder à nos pods du backend, on ajoute souvent une policy qui bloque tout :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress: []

Configurer une Network Policy, c’est simple mais strict : si une règle n’est pas définie, l’accès est refusé (dès qu’une policy s’applique). C’est ce qui rend ce mécanisme si puissant. Je recommande toujours de tester chaque changement, car une erreur peut vite couper des communications essentielles dans le cluster.

Meilleures pratiques pour les Network Policies Kubernetes

Avec le temps et l’expérience, j’ai identifié quelques règles simples qui m’aident à garder mes Network Policies efficaces, lisibles et sûres. Voici les bonnes pratiques que j’applique systématiquement dans mes clusters :

Commencer par une politique par défaut restrictive

Dès qu’un service est sensible ou critique, je définis une policy qui bloque tout par défaut (Ingress et/ou Egress), puis j’ouvre uniquement ce qui est nécessaire. Cela évite les oublis et réduit considérablement les risques.
Utiliser des labels clairs et cohérents

Les policies reposent entièrement sur les labels. Je prends donc le temps de structurer un schéma de labellisation logique (par environnement, rôle, application) pour que mes règles soient prévisibles et compréhensibles.
Limiter le trafic inter-namespaces

Par défaut, le trafic entre namespaces est autorisé. Je le restreins systématiquement aux cas où c’est vraiment utile, en utilisant namespaceSelector.
Documenter chaque Network Policy

Une policy sans explication devient vite incompréhensible. J’ajoute toujours un commentaire ou un champ description dans la metadata (ou un fichier adjacent) pour expliquer à quoi sert la règle.
Déployer progressivement

Je ne change jamais toutes les policies d’un coup. J’ajoute une règle, je la teste, je vérifie son impact, puis je passe à la suivante. Cela évite de tout casser par inadvertance.
Tester les flux avec des outils adaptés

Pour valider mes configurations, j’utilise souvent des pods temporaires comme busybox ou netshoot pour tester la connectivité. Cela me permet de simuler des appels et d’identifier rapidement les blocages.
Tenir compte des CNI

Comme mentionné plus haut, je m’assure toujours que le plugin réseau en place prend bien en charge les Network Policies. Sinon, mes règles ne seront que du vent.
Surveiller l’évolution du cluster

Des changements de labels, de namespace ou de configuration réseau peuvent rendre une policy obsolète. Je fais régulièrement des audits pour m’assurer que mes règles sont encore valides et efficaces.

Appliquer ces bonnes pratiques m’a évité bien des mauvaises surprises. Les Network Policies sont puissantes, mais demandent rigueur et méthode. Une politique mal appliquée peut bloquer un service critique ou, pire, laisser un accès ouvert sans qu’on s’en rende compte.

Contrôle de connaissances

Pourquoi ce contrôle ?

Cet contrôle va vous permettre de valider vos connaissances sur le sujet abordé dans le guide. Il comporte des QCM, des questions vrai/faux et des réponses ouvertes à un mot.

🕒 Le chronomètre commence dès que vous cliquez sur Démarrer le test. Vous devrez terminer l’examen avant la fin du temps imparti.

🎯 Pour réussir, vous devez obtenir au moins 90% de bonnes réponses.

💡 Je ne fournis pas directement les réponses aux questions. Cependant, si certaines sont complexes, des pistes d’explication pourront être proposées dans le guide ou après l’examen.

Bonne chance ! 🚀

Conclusion

Les Network Policies sont un levier essentiel pour sécuriser le trafic réseau dans Kubernetes. En apprenant à les maîtriser, j’ai découvert un outil simple mais puissant pour cloisonner les services, limiter les accès, et appliquer une vraie stratégie de sécurité réseau. Même si leur prise en main demande un peu de rigueur, les bénéfices qu’elles apportent en valent largement l’effort.