DevOps Bootcamp · Leçon

Politiques réseau pour l’isolation

Contrôlez le flux du trafic réseau entre les Pods et les espaces de noms à l’aide des politiques réseau Kubernetes.

Leçon 2 sur 411 étapes

Politiques réseau pour l’isolation est une leçon DevOps Bootcamp gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage DevOps Bootcamp, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours DevOps Bootcamp comprend 4 leçons au total.

Stratégies réseau : les agents de la circulation

Dans Kubernetes, les pods peuvent communiquer librement entre eux par défaut. C’est pratique pour la flexibilité, mais pas toujours idéal pour la sécurité.

Les stratégies réseau jouent le rôle de pare-feu pour vos pods : elles contrôlent le trafic réseau autorisé en entrée (ingress) et en sortie (egress).

Par défaut : tous les pods peuvent communiquer

Par défaut, une fois déployé, un pod peut communiquer avec n’importe quel autre pod du cluster, quel que soit son espace de noms. Ce modèle de « réseau plat » simplifie la configuration, mais n’assure aucune isolation.

Dans les environnements de production, vous devez souvent limiter les communications afin de renforcer la sécurité et d’empêcher les accès non autorisés entre les composants de l’application.

Règles d’entrée et de sortie

Les stratégies réseau définissent les règles qui déterminent comment les pods peuvent communiquer. Elles portent principalement sur deux types de trafic :

Ingress : trafic entrant vers un pod.
Egress : trafic sortant d’un pod.

Ces règles s’appliquent à des pods précis à l’aide d’étiquettes et peuvent cibler d’autres pods, des espaces de noms ou des blocs d’adresses IP.

Prérequis du module d’extension CNI

Les stratégies réseau ne sont pas magiques ! Pour fonctionner, votre cluster Kubernetes doit disposer d’un module d’extension d’interface réseau de conteneurs (CNI) qui les prend en charge.

Des modules d’extension CNI populaires comme Calico, Cilium et Weave Net fournissent cette fonctionnalité. Sans CNI compatible, les stratégies réseau n’auront aucun effet.

Anatomie d’une stratégie

Les stratégies réseau sont définies avec YAML. Parmi les champs clés figurent :

metadata.name : nom unique de votre stratégie.
spec.podSelector : sélectionne les pods auxquels cette stratégie s’applique.
spec.policyTypes : indique si la stratégie s’applique à Ingress, à Egress ou aux deux.
spec.ingress/spec.egress : liste les règles du trafic autorisé.

Bloquer tout le trafic entrant

Créons une stratégie qui refuse tout le trafic entrant vers les pods portant l’étiquette app: backend dans l’espace de noms actuel. C’est un point de départ courant pour une posture de sécurité « refus par défaut ».

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-backend-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress: [] # An empty ingress list denies all incoming traffic

Autoriser l’entrée depuis le serveur frontal

Modifions maintenant notre stratégie pour autoriser le trafic entrant uniquement depuis les pods portant l’étiquette app: frontend dans le même espace de noms, vers nos pods app: backend.

Remarquez la section from, qui indique les pods sources.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Contrôler le trafic sortant

Comme pour le trafic entrant, vous pouvez contrôler le trafic sortant (egress). Nous allons ici créer une stratégie qui autorise les pods app: backend à envoyer des requêtes uniquement vers les pods portant l’étiquette app: database.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-to-db
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database

Cibler d’autres espaces de noms

Que faire si votre serveur frontal se trouve dans un autre espace de noms, par exemple web-apps ? Vous pouvez utiliser namespaceSelector pour cibler des pods dans différents espaces de noms.

Cette stratégie autorise le trafic entrant vers les pods app: backend depuis n’importe quel pod de l’espace de noms web-apps.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-apps-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: web-apps
      podSelector: {} # All pods in the selected namespace

Défi sur les stratégies

Considérez un pod portant les étiquettes app: web et env: prod. Quelle stratégie réseau autoriserait uniquement le trafic entrant depuis les pods de l’espace de noms monitoring ?

Réponds-y dans la leçon interactive

Récapitulatif : sécurisez votre réseau

Excellent travail ! Vous avez appris comment les stratégies réseau de Kubernetes fournissent une isolation réseau essentielle à vos applications.

Elles jouent le rôle de pare-feu pour les pods.
Elles contrôlent le trafic entrant et sortant.
Elles nécessitent un module d’extension CNI qui les prend en charge.
Elles sont définies avec YAML à l’aide de podSelector, de policyTypes et de définitions de règles.
Elles peuvent cibler des pods à l’aide d’étiquettes et même des espaces de noms entiers.

Utilisez-les pour appliquer un modèle réseau fondé sur le « moindre privilège » !

Gratuit pour commencer

Apprends DevOps Bootcamp avec un tuteur IA — gratuit

Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.

Cours: 142
Leçons: 568

Commencer gratuitement Voir le cours complet

Questions Fréquemment Posées

La leçon « Politiques réseau pour l’isolation » est-elle gratuite ?

Oui — le texte complet de « Politiques réseau pour l’isolation » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours DevOps Bootcamp, passe à CoddyKit PRO. Le cours DevOps Bootcamp comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Politiques réseau pour l’isolation » ?

Contrôlez le flux du trafic réseau entre les Pods et les espaces de noms à l’aide des politiques réseau Kubernetes. Tu pratiques DevOps Bootcamp avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer DevOps Bootcamp ?

Aucune expérience préalable n'est requise. DevOps Bootcamp sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Politiques réseau pour l’isolation » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon DevOps Bootcamp ?

Oui. Chaque leçon DevOps Bootcamp inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Contrôle d’accès basé sur les rôles (RBAC)
Politiques réseau pour l’isolation
Normes de sécurité des Pods
Comptes de service et identité des charges de travail

← Retour à DevOps Bootcamp