Isolation réseau multi-tenant avec VPC et NetworkPolicy

Isoler plusieurs tenants dans le cloud ne consiste pas à empiler des règles de pare-feu jusqu’à obtenir un diagramme illisible. La bonne architecture segmente à plusieurs couches, attribue une responsabilité à chacune et refuse par défaut les flux qui n’ont pas de raison métier explicite.

→ Lire l’explication complète de la marmotte

VPC, comptes et frontières de tenants

Un VPC (Virtual Private Cloud) est un réseau virtuel isolé chez un fournisseur cloud. Il fournit une plage d’adresses, des sous-réseaux, des tables de routage et des points de sortie. Il ne constitue pas, à lui seul, une frontière suffisante entre tenants applicatifs. Un VPC partagé avec des sous-réseaux par tenant réduit le coût opérationnel, mais concentre les erreurs de routage, les règles trop larges et les privilèges d’administration dans le même domaine de défaillance.

Le compromis central est net : plus la frontière est haute dans la hiérarchie cloud, plus l’isolation est crédible et la délégation administrative nette, mais plus les interconnexions, observabilités et déploiements coûtent cher. Pour des tenants ayant des administrateurs, des obligations réglementaires ou des niveaux de confiance distincts, la recommandation est de séparer les comptes ou abonnements cloud, puis les VPC. Le VPC partagé reste acceptable pour des tenants internes de même niveau de confiance, à condition que les identités d’administration, les journaux et les règles réseau soient elles aussi séparés. Des étiquettes sur des ressources partagées ne sont pas une frontière de sécurité. C’est de la décoration avec un tableur derrière.

Un plan d’adressage doit empêcher les chevauchements entre VPC appelés à communiquer. Des blocs CIDR (Classless Inter-Domain Routing) distincts par environnement, région et domaine de sécurité permettent de contrôler les routes sans règles ambiguës. Réserver des plages pour l’administration, les services partagés, les charges de travail et la sortie Internet évite le grand classique : un réseau ajouté en urgence qui recouvre le futur réseau de reprise.

Le peering direct entre VPC ne doit pas devenir un maillage complet. Une topologie hub-and-spoke, avec un réseau de transit contrôlé, limite les chemins possibles et centralise l’inspection. Le transit ne doit propager que les routes nécessaires. Annoncer toutes les routes privées à tous les tenants transforme une erreur de règle en surface de mouvement latéral. Les bases du routage et de l’adressage restent détaillées dans les plans IPv4 et CIDR.

Security groups et filtrage des flux Est-Ouest

Un security group, ou groupe de sécurité, est un pare-feu logique attaché à une interface réseau, une machine virtuelle ou une charge de travail selon le fournisseur. Il doit porter la politique de flux entre zones : application vers base de données, relais de supervision vers agent, passerelle d’entrée vers frontal. Les listes de contrôle d’accès de sous-réseau complètent ce filtrage pour bloquer des catégories de trafic au niveau du segment, mais ne remplacent pas des règles attachées aux charges de travail.

La règle de départ est le refus implicite en entrée et en sortie, puis l’ouverture par destination, port et protocole justifiés. Autoriser une plage entière parce qu’elle est « interne » revient à déclarer que toute compromission interne est hors périmètre. C’est précisément l’hypothèse que le cloisonnement doit contester.

Préférer les références à des groupes de sécurité plutôt que les adresses IP fixes lorsque le fournisseur le permet. Une règle « le groupe api peut joindre le groupe database sur 5432/TCP » survit au remplacement d’instances et limite l’autorisation aux membres déclarés. En revanche, cette commodité ne prouve pas que l’identité applicative est légitime : toute charge capable de rejoindre le groupe hérite du chemin réseau.

Le filtrage sortant mérite la même rigueur que le filtrage entrant. Une charge compromise avec une sortie libre peut exfiltrer des données, télécharger un outil ou joindre une infrastructure de commande. Autoriser les résolveurs DNS (Domain Name System), les dépôts approuvés, les points de collecte de journaux et les dépendances externes nommées réduit cette marge. Quand des destinations externes changent fréquemment, passer par un proxy de sortie authentifié et journalisé est préférable à une liste d’adresses IP devenue fossile dès sa création. Les choix de proxy et de chemin réseau relèvent aussi de l’architecture cyber.

Les règles doivent être testées dans les deux sens. Un groupe de sécurité stateful, c’est-à-dire conservant l’état des connexions, autorise généralement les paquets de réponse sans règle inverse. Une liste de contrôle d’accès stateless, c’est-à-dire sans mémoire des connexions, exige aussi les ports de retour éphémères. Confondre les deux produit des incidents où la connexion semble partir correctement puis meurt dans une dignité toute administrative.

Kubernetes et NetworkPolicy entre charges de travail

Dans Kubernetes, une NetworkPolicy est une ressource déclarative qui limite les communications des pods, les unités d’exécution applicative. Elle ne produit aucun effet sans CNI (Container Network Interface), le composant réseau du cluster, capable de l’appliquer. Installer des politiques sur un CNI qui les ignore donne un sentiment de contrôle particulièrement fluide : rien ne bloque, surtout pas l’attaquant.

La politique recommandée est un refus par défaut entrant et sortant dans chaque espace de noms Kubernetes, puis des exceptions minimales. Un espace de noms n’est pas une frontière réseau automatique. Il organise les objets, les droits d’accès et les quotas, mais sans politique réseau, deux pods de cet espace ou d’espaces distincts peuvent souvent communiquer selon la configuration du cluster.

Les sélecteurs de labels doivent identifier une fonction stable, pas une version de déploiement ni une équipe. Une règle fondée sur role=api résiste à un remplacement de pods. Une règle fondée sur release=2026-09-23 fabrique une panne à retardement, ce qui est une tradition plus ancienne que les conteneurs eux-mêmes.

Les politiques doivent aussi traiter les dépendances invisibles : DNS, métadonnées cloud, collecte de logs, métriques, registres d’images et services d’authentification. Bloquer toutes les sorties sans lister ces flux fait échouer le démarrage ou la résolution de noms. Les ouvrir vers tout le cluster annule le bénéfice du refus par défaut. La page conteneurs, Kubernetes, CNI et service mesh couvre les interactions générales entre ces couches ; ici, la priorité reste la séparation de tenants avant le chiffrement applicatif.

Exemple de politique réseau reproductible

L’exemple suivant isole l’espace de noms tenant-a. Il suppose un cluster Kubernetes avec un CNI appliquant les NetworkPolicy et un service DNS portant le label k8s-app=kube-dns dans l’espace de noms kube-system. Les labels doivent être vérifiés sur le cluster cible : les valeurs changent selon les distributions, parce que l’uniformité était manifestement trop reposante.

# Refus entrant et sortant pour tous les pods de tenant-a.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# L'API reçoit seulement le trafic des pods frontend du même tenant.
# Elle peut résoudre des noms et joindre PostgreSQL sur le port 5432.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-required-flows
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:
      role: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
    - to:
        - podSelector:
            matchLabels:
              role: database
      ports:
        - protocol: TCP
          port: 5432

Appliquer avec kubectl apply -f isolation-tenant-a.yaml, puis vérifier depuis un pod frontend et depuis un pod sans le label attendu. Le test doit confirmer l’accès autorisé, le refus vers un autre tenant et le refus de sortie non déclarée. Tester uniquement le chemin nominal valide une démo, pas une barrière.

Surface d’attaque et limites de la segmentation

La segmentation réseau réduit le mouvement latéral, l’exfiltration et l’exposition accidentelle. Elle ne corrige pas une identité compromise, une application vulnérable ou une autorisation métier erronée. Une charge autorisée à joindre une base peut toujours lire les données auxquelles ses identifiants donnent accès. La frontière réseau doit donc être complétée par des identités de charge, des permissions minimales et une authentification applicative. Les principes d’IAM cloud restent indispensables.

Les attaques fréquentes exploitent les chemins oubliés : accès au service de métadonnées cloud, règles de sortie universelles, bastion capable de joindre tous les réseaux, dépendance partagée non segmentée, ou route de transit trop généreuse. Le service de métadonnées doit exiger des jetons lorsque le fournisseur le permet, être inaccessible aux pods non concernés et ne jamais distribuer un rôle cloud surdimensionné.

Le DNS constitue aussi une voie d’exfiltration et de contournement. Journaliser les requêtes, limiter les résolveurs autorisés et bloquer les résolutions directes vers Internet réduisent ce risque. Une politique réseau ne détecte pas une requête HTTPS chiffrée vers une destination autorisée. Le contrôle de contenu, la détection d’anomalies et la protection des données doivent venir d’autres couches.

Enfin, les security groups et NetworkPolicy ne remplacent pas le chiffrement entre services. Ils décident qui peut tenter une connexion, pas si le pair distant est authentique ni si les données restent confidentielles sur un chemin compromis. Un service mesh peut apporter cette authentification de charge à charge, mais ne doit pas devenir l’unique frontière. Le mesh qui chiffre tout dans un réseau plat protège les conversations, pas le droit de les initier.

Exploitation, preuves et reprise

Les règles réseau sont du code d’infrastructure. Les gérer par revue, dépôt versionné et déploiement automatisé permet de comparer l’état déclaré à l’état réel. Une modification manuelle d’urgence doit être réconciliée rapidement, sinon elle devient une permission éternelle avec une justification évaporée.

Activer les journaux de flux au niveau VPC, les journaux de refus des politiques Kubernetes et les événements de modification des règles. Les conserver dans un domaine distinct de celui qui produit les charges de travail. Une compromission d’administrateur réseau ne doit pas permettre d’effacer tranquillement les preuves avant le café.

La supervision doit alerter sur trois signaux : création de routes inter-tenants, élargissement d’une règle à 0.0.0.0/0, et refus réseau soudain sur un flux critique. Mesurer aussi les flux réellement observés avant de supprimer une règle, mais ne jamais générer automatiquement des autorisations depuis ces observations. Le trafic historique décrit ce qui est arrivé, pas ce qui est légitime.

Sauvegarder les configurations VPC, groupes de sécurité, tables de routes, politiques Kubernetes et associations d’identité. La reprise doit pouvoir reconstruire les frontières dans le bon ordre : réseau, routes, filtrage, puis charges de travail. Restaurer les applications avant les règles produit une fenêtre d’exposition. Restaurer les règles avant les dépendances produit une panne contrôlée, ce qui est généralement le meilleur des deux ennuis.

🐝 Ce qui arrive si on s’en passe

Sans segmentation refusant par défaut les flux sans raison métier, un incident dans un tenant ou un service devient une promenade libre dans tout l’environnement. Un composant compromis atteint alors des réseaux, des bases et des charges de travail qui n’avaient aucune raison de lui être accessibles, et le mouvement latéral remplace l’isolation prévue par le diagramme. La conséquence est double : un attaquant élargit son emprise sans nouvelle vulnérabilité, simplement parce que rien ne borne les communications est-ouest, et une fuite ou un abus d’un tenant contamine les données des autres locataires partageant la même infrastructure. La traçabilité en souffre aussi, car des flux autorisés implicitement laissent peu de traces exploitables. Empiler des règles de pare-feu sans posture de refus par défaut produit un diagramme illisible qui autorise silencieusement ce qu’il prétend contenir.

🦫 Explication de la marmotte 🍫

Dans un environnement cloud, plusieurs groupes peuvent utiliser les mêmes infrastructures sans devoir pouvoir se contacter. La séparation commence par créer des réseaux virtuels distincts quand les groupes ont des responsabilités ou des niveaux de confiance différents. Chaque réseau reçoit ses propres adresses, chemins de circulation et règles d’accès.

Des règles de filtrage sont ensuite placées près des machines et des applications. Elles indiquent quelles communications sont autorisées, par exemple une application vers sa base de données sur un port précis. Tout ce qui n’est pas autorisé est refusé. Les sorties vers Internet doivent aussi être limitées, sinon un programme compromis peut envoyer des données ou télécharger des outils dangereux.

Dans un cluster qui exécute des applications emballées dans des conteneurs, des règles supplémentaires contrôlent les échanges entre ces applications. Elles ne fonctionnent que si le composant réseau du cluster sait les appliquer. Il faut donc vérifier ce point avant de compter sur elles.

Cette séparation ne suffit pas si une application possède déjà un identifiant volé ou une permission excessive. Les droits d’accès aux données, l’authentification entre applications et le chiffrement restent nécessaires. Enfin, les règles doivent être enregistrées, surveillées et sauvegardées. Si une règle devient trop large ou disparaît pendant une restauration, la séparation peut échouer sans bruit.

Pages voisines

La citent

Isolation réseau multi-tenant avec VPC et NetworkPolicy

Elle cite

Isolation réseau multi-tenant avec VPC et NetworkPolicy

Isolation réseau multi-tenant avec VPC et NetworkPolicy

VPC, comptes et frontières de tenants

Security groups et filtrage des flux Est-Ouest

Kubernetes et NetworkPolicy entre charges de travail

Exemple de politique réseau reproductible

Surface d’attaque et limites de la segmentation

Exploitation, preuves et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines