# Google Cloud : ClusterNetworkPolicy pour sécuriser les charges IA sur GKE

_Publié le 10 novembre 2026 — https://ip73.fr/2026/11/10/google-cloud-clusternetworkpolicy-pour-securiser-les-charges-ia-sur/_

L'annonce de Google Cloud introduit le ClusterNetworkPolicy (CNP) sur Google Kubernetes Engine (GKE). Cette fonctionnalité permet de dépasser les limites des politiques réseau standard, qui se limitent à l'application au niveau du *namespace*. Le CNP donne aux administrateurs la capacité d'imposer des règles de sécurité fines sur l'intégralité du cluster, une nécessité accrue avec le déploiement de charges de travail d'intelligence artificielle sensibles, comme les modèles LLM.

En expérimentant cette capacité, Google Cloud détaille une approche en trois niveaux : la couche administrative, la couche réseau et la couche de base. Ce modèle vise à créer une posture de sécurité en profondeur, essentielle lorsque des applications critiques, telles qu'un modèle Gemma 4 tournant sur des accélérateurs TPU v5e, doivent être protégées contre tout accès non autorisé.

Pour illustrer ce dispositif, Google Cloud présente une configuration où les pods sont isolés en trois *namespaces* distincts : `gemma-llm` pour le cœur de l'IA, `client-ns` pour les utilisateurs autorisés, et `untrusted-tenant` simulant un client malveillant. Par défaut, dans Kubernetes, tout le trafic entre *namespaces* est ouvert, ce qui rend cette isolation indispensable.

## Le fonctionnement hiérarchisé des politiques

Le CNP repose sur une hiérarchie de précédence. Au sommet, la couche administrative impose des règles obligatoires que personne ne peut contourner, par exemple en bloquant l'accès aux métadonnées. En dessous, les équipes applicatives gèrent les politiques spécifiques à leur *namespace*. Tout au bas, la couche de base établit des garde-fous par défaut, comme un refus systématique des connexions.

L'implémentation d'un état de « zéro confiance » commence par cette couche de base. L'administrateur applique une CNP pour interdire tout accès entrant au cluster. Cependant, cette règle globale doit prévoir une exception explicite pour le trafic DNS sur les ports 53 TCP et UDP ; sans cela, la résolution de noms au sein du cluster échouerait.

Une fois cette base établie, l'équipe responsable du LLM peut déléguer l'accès. Elle définit une politique réseau standard au niveau du *namespace* pour autoriser explicitement le trafic entrant sur le port 8000 uniquement depuis les pods du *namespace* `client-ns`. Les tentatives d'accès provenant du *namespace* non autorisé, en revanche, ne correspondent pas à cette règle intermédiaire, passent à la couche de base et sont alors rejetées.

## Au-delà du réseau : gestion des ressources et compétences

Cette granularité des contrôles est d'autant plus pertinente qu'elle s'inscrit dans un contexte d'optimisation des ressources. D'ailleurs, un rapport de 2026 indiquait que l'utilisation moyenne des CPU sur GKE atteignait seulement 8 %, tandis que 69 % des clusters affichaient un surdimensionnement des requêtes CPU. Les ressources allouées, même si elles sont sécurisées, peuvent représenter un coût important si elles ne sont pas ajustées au comportement réel des *workloads*.

En parallèle de ces avancées en matière de contrôle réseau, le CNCF a récemment lancé la certification Certified Kubernetes Network Engineer (CKNE). Ce diplôme valide une expertise pratique dans la conception, la sécurisation et le dépannage des réseaux Kubernetes en environnement de production. Les ingénieurs voient ainsi formalisée la compétence nécessaire pour gérer des infrastructures de plus en plus complexes, notamment celles qui supportent des charges de travail d'IA.

Les infrastructures modernes exigent donc une double vigilance : d'une part, ériger des murs de sécurité comme le fait le CNP, et d'autre part, s'assurer que les applications ne demandent pas plus de ressources qu'elles n'en consomment réellement, un arbitrage que les équipes techniques doivent maîtriser.

## Sources

- [Experimenting with ClusterNetworkPolicy in GKE](https://cloud.google.com/blog/topics/developers-practitioners/experimenting-with-clusternetworkpolicy-in-gke/), Google Cloud, 10 novembre 2026
- [GKE Is Built on Google’s Kubernetes Expertise – So Why is it Still Underutilized?](https://cloudnativenow.com/features/gke-is-built-on-googles-kubernetes-expertise-so-why-is-it-still-underutilized/), Cloud Native Now, 3 novembre 2026
- [CNCF Launches Certified Kubernetes Network Engineer Certification (CKNE) to Advance Production Ready Networking Skills for AI Era](https://www.cncf.io/announcements/2026/11/10/cncf-launches-certified-kubernetes-network-engineer-certification-ckne-to-advance-production-ready-networking-skills-for-ai-era/), CNCF, 10 novembre 2026 (contenu sous licence CC BY 3.0)