Comment Isoler les Environnements dans un Cluster Kubernetes : VLANs et Network Policies

On me demande souvent comment installer un cluster Kubernetes tout en assurant l’isolation entre différents environnements comme la DMZ, la PROD, et la QUALIF. Il existe plusieurs façons de répondre à cette problématique, mais la plus simple et efficace consiste à configurer des adresses IP multiples de chaque VLAN directement sur les nœuds du cluster, et à gérer la segmentation du trafic avec des Network Policies.

Il est essentiel de comprendre que dans Kubernetes, la gestion réseau est plus dynamique qu’avec les VLANs traditionnels. La sécurité et l’isolation sont souvent gérées directement via des politiques réseau internes, et non simplement au niveau de l’infrastructure physique.

Le Réseau dans Kubernetes : Un Nouveau Monde

Dans une infrastructure réseau traditionnelle, on utilise généralement des VLANs, des firewalls, et des règles de routage pour séparer les environnements comme la DMZ et la PROD. En revanche, dans Kubernetes, la gestion réseau se fait de manière plus fine avec des CNI (Container Network Interfaces), comme Calico. Ces outils permettent de définir comment les pods (les unités de travail dans Kubernetes) communiquent entre eux.

La Sécurité dans Kubernetes

Par défaut, tous les pods dans un cluster Kubernetes peuvent se parler. Cela peut poser un problème de sécurité si tu as des environnements critiques comme la PROD et la DMZ, qui ne devraient pas échanger de données. C’est ici que les Network Policies interviennent pour permettre ou bloquer les communications réseau au sein du cluster.

Solution 1 : Utiliser des IPs Multiples et des Network Policies

La solution la plus simple pour isoler tes environnements est d’attribuer plusieurs adresses IP sur chaque nœud Kubernetes, chaque adresse IP étant associée à un VLAN distinct (par exemple : DMZ, PROD, QUALIF). Ensuite, tu peux gérer la segmentation du trafic avec des Network Policies.

Pourquoi cette approche est simple ?

  • Pas besoin d’outils complexes : Tu configures simplement plusieurs IPs sur les nœuds, correspondant aux VLANs déjà en place dans ton infrastructure réseau.
  • Network Policies : Ce sont elles qui feront le travail pour isoler le trafic entre les environnements. Tu as un contrôle très précis sur les communications.

Comment mettre en place cette solution ?

  1. Configurer les VLANs sur les nœuds Kubernetes : Chaque nœud du cluster aura plusieurs adresses IP, chacune correspondant à un VLAN (exemple : une IP pour le VLAN de la DMZ, une autre pour celui de la PROD, etc.).
  2. Utiliser les Network Policies : Ces politiques permettent de définir quels pods ou namespaces peuvent communiquer entre eux. Par exemple, tu peux empêcher les pods de la DMZ d’accéder à ceux de la PROD, tout en autorisant certaines exceptions spécifiques.

Exemple d’Utilisation de Network Policies pour Isoler les Environnements

Prenons un exemple concret : Tu veux interdire toute communication entre les pods de la DMZ et ceux de la PROD. Cela peut être fait en utilisant une Network Policy basée sur les namespaces. Voici comment la configuration fonctionne :

Politique d’isolation par Namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-dmz-to-prod
  namespace: prod
spec:
  podSelector: {}  # Applique cette règle à tous les pods du namespace "prod"
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          environment: dmz

Dans cet exemple :

  • Namespace « prod » : La politique est appliquée dans le namespace prod.
  • PodSelector : En le laissant vide ({}), la politique s’applique à tous les pods de ce namespace.
  • NamespaceSelector : Il spécifie que la règle concerne le namespace qui a le label environment: dmz, donc les pods du namespace dmz ne peuvent plus envoyer de trafic vers les pods de prod.

Pourquoi utiliser les Labels ici ?

Les labels sur les namespaces permettent de gérer dynamiquement les politiques réseau. Si tu as plusieurs namespaces (par exemple dmz-web, dmz-api), tu peux tous les étiqueter avec environment: dmz, ce qui te permet de créer une règle commune pour tous ces namespaces.

Exemple d’Isolation Complète entre les Namespaces (Sauf via l’Ingress)

Si tu veux isoler complètement tes environnements (chaque namespace est isolé des autres) mais que tu veux autoriser le trafic via un Ingress Controller (comme NGINX), tu peux configurer une Network Policy qui bloque tout sauf le trafic venant d’un Ingress.

Voici un exemple qui interdit toute communication inter-namespace sauf via Ingress :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace-traffic
  namespace: prod  # Applique cette règle dans le namespace "prod"
spec:
  podSelector: {}  # Applique cette règle à tous les pods du namespace "prod"
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}  # Bloque tout trafic provenant d'autres namespaces
  - from:
    - podSelector: {}  # Cela permet les connexions via Ingress

Dans cet exemple :

  • Tous les namespaces sont bloqués : Aucune communication entre les namespaces n’est autorisée par défaut.
  • Seul l’Ingress est autorisé : Le trafic qui passe par un Ingress Controller (un service externe exposé) est autorisé, car l’Ingress est lié directement au pod via des services spécifiques.

Alternative 1 : Multus CNI pour la Gestion de Plusieurs Interfaces Réseau

Une autre approche consiste à utiliser Multus CNI, qui permet d’affecter plusieurs interfaces réseau à chaque pod. Cela peut être intéressant si tu souhaites isoler les environnements via des interfaces distinctes au lieu d’utiliser plusieurs adresses IP sur les nœuds.

Comment ça marche ?

  • Multus permet plusieurs interfaces : Chaque pod peut avoir plusieurs interfaces réseau. Par exemple, une interface pour le réseau DMZ, une autre pour PROD, etc.
  • Gestion des VLANs : Chaque interface peut être associée à un VLAN spécifique, te permettant de gérer physiquement la segmentation du trafic.

Avantages

  • Isolation physique stricte : Chaque environnement dispose de sa propre interface réseau.
  • Granularité : Tu peux définir des interfaces spécifiques pour chaque environnement.

Inconvénients

  • Complexité accrue : Configurer Multus nécessite plus de travail et augmente la charge de gestion.

Alternative 2 : Clusters Séparés pour Chaque Environnement

Une approche encore plus radicale consiste à déployer plusieurs clusters Kubernetes séparés pour chaque environnement (DMZ, PROD, QUALIF). Chaque cluster aurait son propre réseau et CNI, garantissant une isolation totale.

Avantages

  • Isolation complète : Chaque environnement est totalement isolé au niveau des clusters, sans partage des ressources réseau.

Inconvénients

  • Coût élevé : Mettre en place et gérer plusieurs clusters demande beaucoup de ressources et de temps.

Conclusion : Utiliser les IPs Multiples et les Network Policies pour une Simplicité Maximale

Pour isoler efficacement tes environnements tout en minimisant la complexité, la solution la plus simple est de configurer plusieurs IPs pour chaque VLAN sur les nœuds Kubernetes, puis d’utiliser des Network Policies pour gérer la segmentation du trafic. Cela te permet de tirer parti des VLANs déjà en place dans ton infrastructure tout en gardant une flexibilité maximale dans Kubernetes.

Si tu cherches une solution plus stricte ou granulaire, tu peux envisager d’utiliser Multus CNI ou même de déployer des clusters Kubernetes séparés. Toutefois, pour la majorité des cas, l’approche via les IPs multiples et Calico est un compromis idéal entre simplicité et efficacité. Un autre compromis intéressant qui combine le meilleur des deux mondes est Harvester, une solution HCI qui simplifie la gestion des infrastructures virtualisées et Kubernetes en offrant une plateforme unifiée.

Étiquettes

Publications similaires