Référence rapide NetworkPolicies : contrôler le trafic réseau Kubernetes

Les NetworkPolicies constituent le pare-feu natif de Kubernetes. Cette référence rapide NetworkPolicies couvre la syntaxe YAML, les sélecteurs, les règles ingress/egress et les commandes de debug essentielles.

Sans NetworkPolicy, tous les pods communiquent librement. Avec 82% des organisations utilisant Kubernetes en production (CNCF Annual Survey 2025), la maîtrise du contrôle réseau devient indispensable pour tout administrateur système Kubernetes.

TL;DR : Une NetworkPolicy est un objet Kubernetes qui filtre le trafic au niveau pod via des règles ingress (entrant) et egress (sortant). Elle s'applique aux pods correspondant à son podSelector. Sans CNI compatible (Calico, Cilium, Weave), les NetworkPolicies sont ignorées.

Cette compétence est au cœur de la formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes.

---

Syntaxe de base NetworkPolicy

À retenir : Un podSelector: {} vide cible tous les pods du namespace. C'est la base d'une politique "deny-all".

---

Structure YAML complète

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

Cette politique autorise uniquement les pods app: frontend à contacter les pods app: backend sur le port 8080. Consultez le Guide Complet Formation Kubernetes pour approfondir l'architecture réseau.

---

Sélecteurs disponibles

Exemple : sélecteur combiné

ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            project: monitoring
        podSelector:
          matchLabels:
            app: prometheus

À retenir : Quand podSelector et namespaceSelector sont au même niveau (même tiret), c'est un AND logique. Deux tirets séparés = OR logique.

---

Politiques deny-all essentielles

Deny all ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: secure-ns
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Deny all egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: secure-ns
spec:
  podSelector: {}
  policyTypes:
    - Egress

Deny all (ingress + egress)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: secure-ns
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Ces politiques sont fondamentales pour l'examen CKS, qui exige un score de 67% en 2 heures (Linux Foundation). La formation LFS460 couvre ces scénarios en détail.

---

Cas d'usage courants

Autoriser DNS (egress)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Autoriser un CIDR externe

egress:
  - to:
      - ipBlock:
          cidr: 203.0.113.0/24
          except:
            - 203.0.113.128/25
    ports:
      - protocol: TCP
        port: 443

Multi-ports

ingress:
  - from:
      - podSelector:
          matchLabels:
            role: api-client
    ports:
      - protocol: TCP
        port: 80
      - protocol: TCP
        port: 443
      - protocol: TCP
        port: 8080

Retrouvez d'autres exemples dans l'aide-mémoire kubectl.

---

Commandes de debug

Diagnostic rapide

# Vérifier le CNI installé
kubectl get pods -n kube-system | grep -E "calico|cilium|weave"

# Lister les NetworkPolicies d'un namespace
kubectl get netpol -n production

# Voir les pods ciblés par une politique
kubectl get pods -n production -l app=backend

# Tester la connectivité
kubectl exec -it test-pod -- nc -zv backend-svc 8080

À retenir : Sans CNI compatible, kubectl get netpol retourne des objets mais ils n'ont aucun effet. Vérifiez toujours votre CNI.

---

Vérification CNI

Cilium exploite eBPF pour des politiques réseau avancées.

---

Pièges courants

Erreur fréquente : AND vs OR

# OR : autorise ns1 OU pods avec label
- from:
    - namespaceSelector:
        matchLabels:
          name: ns1
    - podSelector:
        matchLabels:
          app: web

# AND : autorise pods avec label DANS ns1
- from:
    - namespaceSelector:
        matchLabels:
          name: ns1
      podSelector:
        matchLabels:
          app: web

---

Tests de connectivité

# Créer un pod de test
kubectl run test-client --image=busybox --rm -it -- sh

# Depuis le pod de test
wget -qO- --timeout=2 http://backend-svc:8080
nc -zv backend-pod-ip 8080

# Vérifier les logs du CNI (Calico)
kubectl logs -n kube-system -l k8s-app=calico-node --tail=50

Pour maîtriser ces techniques de debug, consultez les tutoriels et guides pratiques Kubernetes et le mémo Kubernetes objets et ressources API.

---

Ordre d'évaluation

1. Si aucune NetworkPolicy ne cible un pod : tout le trafic est autorisé
2. Si une NetworkPolicy cible un pod : seul le trafic explicitement autorisé passe
3. Les politiques sont additives : plusieurs politiques = union des règles

À retenir : Une NetworkPolicy vide avec policyTypes: [Ingress] bloque tout le trafic entrant car aucune règle ingress n'est définie.

---

Bonnes pratiques

Adoptez une approche deny-by-default : créez d'abord une politique deny-all, puis ajoutez des exceptions explicites.

Labellisez systématiquement : des labels cohérents (app, tier, env) simplifient la rédaction des politiques.

Documentez chaque politique : ajoutez des annotations expliquant le but de chaque règle.

Testez avant production : validez vos politiques dans un namespace de test avec des pods éphémères.

L'examen CKS teste ces compétences en conditions réelles. Avec 104 000 candidats CKA (croissance de 49% sur un an selon CNCF Training Report), la certification CKS différencie les profils sécurité. Apprenez à déployer votre premier pod avant d'implémenter des politiques complexes.

---

Passez à l'action

Les NetworkPolicies représentent une compétence clé pour la certification CKS et la sécurisation de clusters Kubernetes en production. Pour structurer votre apprentissage :

• Formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes : 4 jours pour maîtriser les NetworkPolicies, admission controllers et runtime security - Formation LFS458 Administration Kubernetes : 4 jours pour consolider vos bases cluster avant la spécialisation sécurité - Kubernetes, les fondamentaux : 1 jour pour découvrir l'écosystème si vous débutez. Pour approfondir, consultez notre formation notre avis sur les meilleures plateformes de labs kubernetes.

Pour approfondir, consultez notre formation tutoriels et guides pratiques kubernetes paris présentiel. Pour approfondir, consultez notre formation Déploiement et mise en production Kubernetes.

Contactez nos conseillers pour construire votre parcours vers la certification CKS.