Les NetworkPolicies Kubernetes

Les NetworkPolicies contrôlent quels Pods peuvent communiquer entre eux et avec l'extérieur au niveau IP et port (L3/L4). Par défaut, Kubernetes n'applique aucune restriction : tous les Pods se parlent librement. Les NetworkPolicies permettent de cloisonner ces flux selon le principe du moindre privilège.

Ce guide couvre la création de policies ingress et egress, les cas critiques comme le DNS, et les techniques de debug indispensables.

Ce que vous allez apprendre

• Comprendre le modèle : sélection par labels, union des règles, logique source/destination
• Créer des policies : deny par défaut, autorisation ciblée, filtrage par namespace
• Gérer l'egress : ne pas casser le DNS, autoriser les flux nécessaires
• Débugger : diagnostiquer pourquoi un flux est bloqué ou autorisé

À quoi servent les NetworkPolicies

En l'absence de toute politique réseau applicable, les Pods communiquent librement entre eux, y compris d'un namespace à l'autre. C'est le comportement permissif par défaut de Kubernetes, et c'est exactement ce qu'une NetworkPolicy vient restreindre.

Les NetworkPolicies permettent de :

• Restreindre les connexions entrantes vers un Pod (ingress)
• Restreindre les connexions sortantes depuis un Pod (egress)
• Isoler des environnements (production, staging, test)
• Limiter la propagation en cas de compromission d'un Pod

Un mot sur le niveau auquel tout cela opère : les NetworkPolicies filtrent aux couches 3 et 4, adresses et ports. Elles ne savent rien des chemins HTTP, des en-têtes ni des méthodes. Un filtrage applicatif de ce genre relève d'un service mesh ou d'un CNI qui propose ses propres extensions, pas de l'objet standard.

Condition préalable : un CNI compatible

Kubernetes définit les NetworkPolicies, mais ne les applique pas lui-même. C'est le plugin réseau (CNI) qui doit implémenter cette fonctionnalité.

Vérifiez votre CNI

Sans CNI compatible, vos manifestes YAML seront acceptés par l'API, mais les règles ne seront pas appliquées. Le trafic passera quand même.

Avant d'écrire des NetworkPolicies, vérifiez dans la documentation de votre plugin réseau qu'il applique bien les policies Kubernetes.

Parmi les implémentations souvent utilisées qui supportent les NetworkPolicies :

CNI	Support NetworkPolicy	Notes
Calico	✅ Complet	Policies étendues disponibles
Cilium	✅ Complet	Filtrage L7 optionnel
Antrea	✅ Complet	Orienté VMware/vSphere
Weave Net	✅ Complet	Dépôt d'origine archivé en juin 2024, seul un fork communautaire est maintenu
Flannel	❌ Aucun	« For network policy, other projects such as Calico can be used » (README amont)
kindnet	✅ Oui	Le CNI par défaut de kind, celui du cluster de cette formation

Glissez pour voir

Vérifier le CNI installé :

kubectl get pods -n kube-system -l k8s-app=calico-node
kubectl get pods -n kube-system -l k8s-app=cilium

Bonne nouvelle pour qui suit cette formation : le cluster kind des leçons précédentes convient. Son CNI, kindnet, applique bien les NetworkPolicies, ce qui n'a pas toujours été le cas et reste peu connu. Vérifié sur kind v0.33 avec kindest/node:v1.37.0 : une requête qui aboutit avant la policy expire après un default deny ingress, et un namespaceSelector filtre bien selon le namespace d'origine. Le comportement en egress n'a pas été établi sur ce cluster, la vérification ayant échoué pour une raison étrangère aux policies : considérez-le comme à confirmer.

Les distributions k3s et RKE2 embarquent Flannel, ce qui pourrait laisser croire que les policies y sont ignorées. C'est faux : k3s ajoute son propre contrôleur de NetworkPolicy, actif par défaut, que l'on désactive avec --disable-network-policy.

Comment fonctionne le modèle

Trois idées suffisent à lire n'importe quelle NetworkPolicy, et elles se rencontrent dans cet ordre : à qui la règle s'applique, ce que sa seule existence change, et comment plusieurs règles se combinent. La deuxième est la plus contre-intuitive, et c'est elle qui produit le plus d'erreurs.

Sélection par labels

Une NetworkPolicy cible les Pods via un podSelector basé sur leurs labels. Sans sélection valide, la policy ne s'applique à aucun Pod.

spec:
  podSelector:
    matchLabels:
      app: backend

Cette policy s'applique uniquement aux Pods ayant le label app: backend dans le namespace où elle est déployée.

Sélectionner tous les Pods d'un namespace :

spec:
  podSelector: {}

Ingress et Egress

Ces deux directions se conçoivent depuis le Pod sélectionné par la policy, jamais depuis le réseau. Ingress désigne ce qui entre dans ce Pod, Egress ce qui en sort. La confusion la plus fréquente vient du mot « Ingress », qui désigne aussi une ressource Kubernetes de routage HTTP : les deux n'ont aucun rapport. Retenez aussi que restreindre l'egress est nettement plus risqué que restreindre l'ingress, parce que c'est la direction qui porte le DNS.

Direction	Contrôle	Quand restreindre
Ingress	Connexions entrantes vers le Pod	Limiter qui peut accéder à un service
Egress	Connexions sortantes depuis le Pod	Limiter où un Pod peut se connecter

Glissez pour voir

L'isolation se décide par direction, et indépendamment. Un policyTypes qui ne mentionne que Ingress laisse le trafic sortant entièrement libre, et réciproquement. C'est une propriété commode, mais elle explique bien des surprises : croire avoir tout fermé alors qu'on n'a fermé qu'un sens.

Déclarez explicitement policyTypes pour éviter les ambiguïtés :

spec:
  policyTypes:
    - Ingress
    - Egress

Union des règles

Les NetworkPolicies ne se remplacent pas l'une l'autre. Les connexions autorisées résultent de l'union de toutes les règles applicables au Pod pour la direction concernée.

Exemple : si deux policies autorisent des sources différentes vers le même Pod, les deux sources sont autorisées.

Policy A : autorise frontend → backend
Policy B : autorise monitoring → backend
Résultat : frontend ET monitoring peuvent accéder à backend

Pas de priorité

Il n'existe pas de système de priorité entre NetworkPolicies standard. Une policy "deny" ne peut pas écraser une policy "allow" existante. Le seul moyen de restreindre est de ne pas autoriser explicitement.

Logique source + destination

Pour qu'une connexion fonctionne, elle doit être autorisée des deux côtés si des restrictions existent :

• L'egress du Pod source doit autoriser la sortie vers la destination
• L'ingress du Pod destination doit autoriser l'entrée depuis la source

Pod A (egress restreint) → Pod B (ingress restreint)

✅ Fonctionne si :
   - Policy egress de A autorise B
   - Policy ingress de B autorise A

❌ Échoue si :
   - L'une des deux policies manque l'autorisation

C'est un point fondamental pour le dépannage : vérifiez toujours les policies des deux côtés.

Premier cas : autoriser frontend vers backend

Commençons par un cas classique : seuls les Pods frontend peuvent accéder aux Pods 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

Ce que fait cette policy :

1. Sélectionne les Pods app: backend dans le namespace default
2. Restreint leur trafic ingress (entrées deviennent contrôlées)
3. Autorise uniquement les connexions depuis les Pods app: frontend
4. Limite au port TCP 8080

Le port d'une policy est celui du conteneur, pas celui du Service

C'est le piège numéro un des NetworkPolicies, et il mérite sa propre section parce qu'il ne se voit pas à la relecture. Le champ port d'une règle désigne le port sur lequel le conteneur écoute, c'est-à-dire le targetPort du Service, jamais le port publié par le Service.

Prenez un Service qui expose 8080 vers un conteneur qui écoute sur 80. Écrire port: 8080 dans la policy bloque tout le trafic : la traduction d'adresse a déjà eu lieu quand le paquet atteint le Pod, et le port que voit la policy est 80. Le symptôme est particulièrement trompeur, puisque la policy paraît correcte et que rien ne passe, sans message d'erreur nulle part.

La vérification tient en une commande, à lancer avant d'écrire la règle :

kubectl get svc backend -o jsonpath='{.spec.ports[0].targetPort}'

Appliquer et tester :

kubectl apply -f allow-frontend-to-backend.yaml

# Depuis un Pod frontend
kubectl exec -it deploy/frontend -- curl backend:8080
# Résultat : connexion réussie

# Depuis un autre Pod
kubectl exec -it deploy/autre-app -- curl backend:8080
# Résultat : bloqué

La forme exacte du blocage dépend du CNI, ne vous fiez pas à un symptôme unique. Un CNI qui pose une règle DROP produit un timeout ; le contrôleur embarqué de k3s renvoie une connexion refusée immédiate. Dans les deux cas la connexion n'aboutit pas, mais un « connection refused » ne signifie pas que votre policy est hors sujet.

Default deny ingress

Pour isoler complètement un namespace ou un groupe de Pods, commencez par bloquer tout le trafic entrant :

Pour tout un namespace

Le manifeste ci-dessous est le plus court du guide et l'un des plus lourds de conséquences. Deux détails le rendent bloquant : podSelector: {} qui, loin de ne rien sélectionner, sélectionne tous les Pods du namespace, et l'absence totale de clé ingress. Une policy sans règle n'autorise rien, c'est ce qui transforme une simple déclaration en blocage complet. Appliquez-la sur un namespace de test avant la production, elle coupe immédiatement l'accès aux applications existantes.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}  # Tous les Pods du namespace
  policyTypes:
    - Ingress
  # Pas de section ingress = rien n'est autorisé

Cette policy :

• Sélectionne tous les Pods du namespace production
• Déclare qu'elle contrôle l'ingress
• N'autorise aucune connexion entrante (pas de règle ingress)

La posture cible est toujours la même : un refus par défaut, puis des autorisations explicites. Interdire au cas par cas laisse toujours un chemin qu'on n'avait pas prévu, et surtout ne dit rien de ce qu'on a oublié.

La séquence pour y arriver dépend du terrain, et c'est là qu'on casse la production. Sur un namespace neuf, posez le refus par défaut en premier : rien ne tourne encore, chaque flux s'ouvre au fur et à mesure. Sur un namespace existant, l'ordre s'inverse : inventoriez les flux réels, écrivez et appliquez les autorisations, vérifiez-les, y compris la résolution DNS, et seulement ensuite posez le refus par défaut. Commencer par le refus sur une application qui tourne, c'est la couper le temps de découvrir ce qu'elle appelait.

Pour un groupe de Pods spécifique

Cette variante limite le blocage aux Pods portant un label précis, ce qui permet d'isoler un composant sensible sans figer tout le namespace. Notez la différence d'écriture avec l'exemple précédent : ici la clé ingress: [] est présente mais vide, alors que plus haut elle était absente. Les deux formes produisent le même résultat, aucune source autorisée ; ingress: [] a simplement le mérite de rendre l'intention explicite pour le prochain lecteur du dépôt.

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

Default deny egress

Restreindre les connexions sortantes est tout aussi important, mais nécessite plus d'attention car cela peut casser des fonctionnalités critiques.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  # Pas de section egress = rien n'est autorisé

Attention au DNS

Un deny egress casse la résolution DNS. Les Pods ne peuvent plus résoudre les noms de services. Vous devez explicitement autoriser le DNS.

Autoriser le DNS

C'est le premier réflexe dès que vous restreignez l'egress. Sans DNS, vos applications ne peuvent plus résoudre mon-service.namespace.svc.cluster.local.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: production
spec:
  podSelector: {}  # Tous les Pods du namespace
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Alternative plus simple (moins restrictive) :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress-simple
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Cette version autorise le port 53 vers n'importe quelle destination. Plus permissive, mais plus simple à maintenir.

Le namespace kube-system porte automatiquement le label kubernetes.io/metadata.name: kube-system, posé par Kubernetes lui-même. C'est ce qui rend la règle DNS ci-dessus portable d'un cluster à l'autre, sans supposer qu'un administrateur ait pensé à étiqueter quoi que ce soit.

Exemple complet : egress contrôlé

Voici une policy qui autorise un Pod à :

• Résoudre le DNS
• Accéder à une base de données PostgreSQL interne
• Rien d'autre

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-controlled
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    # DNS
    - ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    # PostgreSQL interne
    - to:
        - podSelector:
            matchLabels:
              app: postgresql
      ports:
        - protocol: TCP
          port: 5432

Sélection par namespace

Pour autoriser des flux entre namespaces, utilisez namespaceSelector.

Autoriser depuis un namespace spécifique

Le point à surveiller ici est que namespaceSelector sélectionne des labels de namespace, pas un nom. Écrire name: monitoring ne fonctionne que si le namespace porte réellement ce label, ce qui n'est pas automatique. Kubernetes pose bien un label kubernetes.io/metadata.name sur chaque namespace depuis la 1.21, et c'est souvent le sélecteur le plus fiable parce que personne n'a besoin de penser à l'ajouter.

Une fois cette règle appliquée, tous les Pods du namespace monitoring peuvent atteindre le backend, sur n'importe quel port. Pour restreindre à un Pod précis, il faut combiner les deux sélecteurs, ce que couvre la section suivante.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-monitoring
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring

Tous les namespaces reçoivent d'office le label kubernetes.io/metadata.name, dont la valeur est leur propre nom. Un namespaceSelector peut donc toujours désigner un namespace précis, même si personne n'y a jamais ajouté de label. Mesuré sur le cluster de la formation : le filtrage laisse passer le namespace autorisé et bloque les autres.

Combiner namespace et pod selector

Pour cibler des Pods spécifiques dans un namespace spécifique :

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

Attention à la syntaxe : les deux sélecteurs dans le même item - signifie ET logique. Séparés, c'est OU logique :

# ET logique : namespace monitoring ET pod prometheus
- from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
      podSelector:
        matchLabels:
          app: prometheus

# OU logique : namespace monitoring OU pod prometheus (dans le même namespace)
- from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    - podSelector:
        matchLabels:
          app: prometheus

Utiliser ipBlock

ipBlock permet d'autoriser des plages d'adresses IP, typiquement pour des systèmes externes au cluster.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-external-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 203.0.113.0/24
            except:
              - 203.0.113.128/25
      ports:
        - protocol: TCP
          port: 443

Deux limites de ipBlock méritent d'être connues avant de s'en servir. Il raisonne en adresses IP, donc il ne sait rien des pods, dont les adresses changent à chaque recréation : le réserver aux destinations externes au cluster. Et selon le CNI, l'adresse source observée peut être celle du nœud plutôt que celle du pod émetteur, ce qui rend les règles fondées sur des plages internes peu fiables.

Protéger le point de métadonnées du nœud

C'est l'usage le plus important d'except, et il est attendu à la CKS, dont le domaine Cluster Setup demande de « protéger les métadonnées et les points d'accès du nœud ».

Chez un fournisseur de cloud, le nœud interroge un service de métadonnées sur l'adresse lien-local 169.254.169.254, et ce service distribue souvent des identifiants d'accès. Un Pod compromis qui l'atteint hérite des droits du nœud : une intrusion applicative devient une compromission d'infrastructure.

bloquer-metadonnees.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: bloquer-metadonnees
  namespace: production
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32
    - ports:
        - port: 53
          protocol: UDP

La règle DNS doit être ajoutée séparément, et c'est l'oubli qui fait perdre le plus de temps : dès qu'un bloc egress existe, tout ce qui n'y figure pas est refusé, résolution de noms comprise. Un Pod qui ne résout plus rien après la pose d'une politique est presque toujours victime de cela.

Vérifié sur le cluster de la formation : avec cette politique, un Pod atteint normalement les autres Pods et échoue vers l'adresse exclue.

Ce qu'un cluster local ne peut pas prouver

Un cluster kind n'expose aucun service de métadonnées à cette adresse. La politique s'y écrit et s'y applique, mais le blocage ne se démontre pas faute de cible réelle : il faut un nœud cloud.

Ce que les NetworkPolicies ne font pas

Pour éviter les fausses attentes, voici ce que les NetworkPolicies standard ne peuvent pas faire :

Fonctionnalité	NetworkPolicy	Alternative
Filtrer par URL/path HTTP	❌ Non	Service mesh (Istio, Linkerd)
Authentification mutuelle (mTLS)	❌ Non	Service mesh
Filtrer par méthode HTTP (GET, POST)	❌ Non	Service mesh, API Gateway
Inspection de payload	❌ Non	WAF
Logging des connexions bloquées	❌ Non	CNI spécifique (Cilium, Calico)
Policies inter-clusters	❌ Non	Solutions multi-cluster

Glissez pour voir

Les NetworkPolicies sont un premier niveau de segmentation réseau, pas une solution de sécurité applicative complète.

Débugger une NetworkPolicy

Quand un flux est bloqué (ou ne l'est pas alors qu'il devrait), suivez cette méthode :

1. Lister les policies du namespace

   kubectl get networkpolicy -n production

2. Examiner une policy en détail

   kubectl describe networkpolicy allow-frontend-to-backend -n production

   La sortie répond à trois questions, et il faut les poser dans cet ordre : la règle vise-t-elle bien ce Pod, et seulement ensuite, qu'autorise-t-elle ?

   • PodSelector : quels Pods sont ciblés ?
   • Allowing ingress traffic : quelles sources sont autorisées ?
   • Allowing egress traffic : quelles destinations sont autorisées ?

3. Vérifier les labels des Pods

   kubectl get pods -n production --show-labels
   kubectl get pods -n production -l app=backend

   Un Pod sans le bon label ne sera pas sélectionné par la policy.

4. Tester la connectivité

   # Depuis le Pod source
   kubectl exec -it deploy/frontend -n production -- nc -vz backend 8080
   
   # Test DNS
   kubectl exec -it deploy/frontend -n production -- nslookup backend

5. Vérifier les deux côtés

   Si l'egress du source ET l'ingress de la destination sont restreints, vérifiez que les deux autorisent le flux.

   # Policies qui sélectionnent le Pod source (egress)
   kubectl get networkpolicy -n production -o json | \
     jq '.items[] | select(.spec.podSelector.matchLabels.app=="frontend")'
   
   # Policies qui sélectionnent le Pod destination (ingress)
   kubectl get networkpolicy -n production -o json | \
     jq '.items[] | select(.spec.podSelector.matchLabels.app=="backend")'

Outils de debug avancés

Un point de méthode avant de lancer ces commandes : un Pod de debug créé avec kubectl run porte des labels différents de votre application, donc les policies qui protègent celle-ci ne s'appliquent pas à lui. Vous risquez de conclure « le flux passe » alors que vous avez simplement testé depuis un Pod non concerné. Pour un test représentatif, ajoutez les labels de l'application avec --labels="app=frontend", ou utilisez kubectl debug pour attacher un conteneur éphémère au Pod réel.

# Pod de debug avec outils réseau
kubectl run netshoot --rm -it --image=nicolaka/netshoot:v0.16@sha256:b09d9b21381f47a79b3cbcb30da25266dc17186ea00ae65e99fdc51396f48e70 -- bash

# Dans le pod netshoot
nslookup backend.production.svc.cluster.local
curl -v backend.production:8080
nc -vz backend.production 8080

# Vérifier si le CNI loggue les drops (Cilium)
kubectl logs -n kube-system -l k8s-app=cilium -c cilium-agent | grep -i drop

Problèmes courants

Lisez ce tableau en distinguant deux familles de pannes. Les quatre premières lignes décrivent un flux bloqué à tort : la cause est presque toujours une autorisation manquante ou un label qui ne correspond pas, et vous la trouverez en comparant kubectl describe networkpolicy aux labels réels des Pods. La dernière ligne décrit l'inverse, un flux autorisé à tort, et elle se diagnostique différemment : il ne s'agit pas de chercher une erreur dans une policy, mais de lister toutes celles qui sélectionnent le Pod, puisque leurs autorisations s'additionnent.

Symptôme	Cause probable	Solution
Timeout vers un service	Policy ingress manquante côté destination	Ajouter une règle from
DNS ne résout plus	Egress deny sans exception DNS	Autoriser le port 53
Policy ignorée	CNI incompatible	Vérifier le support NetworkPolicy
Pod non sélectionné	Labels incorrects	Vérifier --show-labels
Flux autorisé inattendu	Union de plusieurs policies	Lister toutes les policies applicables

Glissez pour voir

Documenter vos NetworkPolicies

Pour maintenir des policies lisibles dans le temps :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
  annotations:
    description: "Autorise le frontend à accéder au backend sur le port API"
    owner: "team-platform"
    last-review: "2026-03-22"
spec:
  # ...

Une NetworkPolicy n'a aucun champ de description. La seule façon d'expliquer une règle à celui qui la lira dans six mois est donc une annotation, et c'est une discipline qui paie : une policy se lit mal, et personne n'ose supprimer une règle dont il ignore la raison d'être.

Contrôle de connaissances

Sept questions, avec un seuil volontairement haut à 90 % : sur ce sujet, une règle mal comprise se traduit par une application coupée en production ou, pire, par une isolation que vous croyez active alors qu'elle ne l'est pas. Les deux points qui font le plus trébucher sont l'union des policies et la nécessité d'autoriser le flux des deux côtés.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

90% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Ce qu'il faut savoir pour la CKAD

L'examen étant chronométré, l'enjeu n'est pas de connaître toutes les options mais de produire un manifeste correct sans réfléchir à la structure. Les cinq gestes ci-dessous sont ceux qui reviennent ; entraînez-vous à les écrire de mémoire, puis à les vérifier avec kubectl describe. Rappel utile le jour J : kubectl explain networkpolicy.spec --recursive est disponible pendant l'épreuve et vous évite de deviner l'imbrication des champs.

1. Lire une policy existante

   Identifiez rapidement : quels Pods sont sélectionnés (podSelector), quel trafic est contrôlé (policyTypes), quelles règles s'appliquent.

2. Créer un default deny ingress

   podSelector: {}
   policyTypes: [Ingress]
   # Pas de section ingress

3. Autoriser un flux spécifique

   Frontend vers backend, port 8080 :

   ingress:
     - from:
         - podSelector:
             matchLabels:
               app: frontend
       ports:
         - port: 8080

4. Autoriser le DNS en egress

   Dès que vous restreignez l'egress, autorisez UDP/TCP 53.

5. Diagnostiquer un blocage

   • kubectl get networkpolicy -n <ns>
   • kubectl describe networkpolicy <name>
   • kubectl get pods --show-labels
   • kubectl exec ... -- nc -vz <service> <port>

À retenir

1. Les NetworkPolicies opèrent au niveau L3/L4 (IP/port), pas HTTP
2. Le CNI doit supporter l'enforcement des policies, sinon elles sont ignorées
3. Un Pod devient isolé (ingress ou egress) dès qu'une policy le sélectionne
4. Les règles autorisées sont l'union des policies applicables
5. Une connexion doit être autorisée des deux côtés (source egress + destination ingress)
6. Dès que l'egress est restreint, pensez au DNS (port 53)
7. ipBlock est pour les IP externes stables, pas pour cibler des Pods
8. Déclarez explicitement policyTypes pour éviter les ambiguïtés

Mettre en pratique

Trois niveaux d'isolation, tous validés par de vraies connexions et non par la lecture du YAML. Vous isolez d'abord une base pour n'y laisser entrer que son backend, puis cloisonnez trois tiers en ingress et en egress, et terminez par le default deny intégral, celui qui casse silencieusement la résolution DNS tant que vous ne l'avez pas rouverte.

Lab pratique

Isoler la base de données : seul le backend y accède

$ dsoxlab run cka-networkpolicy-isolate-db

Environnement : VM·Durée : ~15 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run cka-networkpolicy-isolate-db
dsoxlab check cka-networkpolicy-isolate-db

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Lab pratique

Cloisonner trois tiers avec des NetworkPolicy ingress et egress

$ dsoxlab run ckad-networkpolicy-ingress-egress

Environnement : VM·Durée : ~20 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run ckad-networkpolicy-ingress-egress
dsoxlab check ckad-networkpolicy-ingress-egress

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Lab pratique

Tout interdire, puis rouvrir le strict nécessaire, DNS compris

$ dsoxlab run cks-networkpolicy-default-deny

Environnement : VM·Durée : ~20 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run cks-networkpolicy-default-deny
dsoxlab check cks-networkpolicy-default-deny

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille l'installation, le calcul du score et les pièges.

Pour aller plus loin

• mTLS pod-to-pod : Le chiffrement et l'authentification du trafic que vos règles laissent passer.
• Falco : La détection des comportements suspects qui franchissent malgré tout le filtrage.
• RBAC Kubernetes : Le pendant de l'isolation réseau côté API, pour les droits des utilisateurs et des Pods.

×

📖 Voir la documentation →