Clusters AKS (Azure Kubernetes Service) isolés du réseau (préversion)

Les organisations ont généralement des exigences de sécurité et de conformité strictes pour réguler le trafic réseau de sortie (sortant) d’un cluster afin d’éliminer les risques d’exfiltration de données. Par défaut, les clusters Azure Kubernetes Service (AKS) disposent d’un accès Internet sortant sans restriction. Ce niveau d’accès réseau permet aux nœuds et services que vous exécutez d’accéder aux ressources externes en fonction des besoins. Si vous souhaitez restreindre le trafic de sortie, un nombre limité de ports et adresses doit être accessible afin de gérer les tâches de maintenance d’intégrité du cluster. Le document conceptuel sur les règles de réseau sortant et de FQDN pour les clusters AKS fournit la liste des points de terminaison nécessaires au cluster AKS ainsi qu’à ses modules complémentaires et fonctionnalités facultatifs.

Pour restreindre le trafic sortant du cluster, il existe une solution qui consiste à utiliser un dispositif de pare-feu permettant de limiter le trafic en fonction des noms de domaine. La configuration manuelle d’un pare-feu avec les règles de sortie et les FQDN nécessaires est un processus lourd et compliqué.

Une autre solution, un cluster AKS isolé du réseau (préversion), simplifie la configuration en établissant de manière prédéfinie des restrictions sur le trafic sortant d’un cluster. L’opérateur du cluster peut ensuite configurer de manière incrémentielle le trafic sortant autorisé pour chaque scénario à activer. Un cluster AKS isolé du réseau réduit ainsi le risque d’exfiltration de données.

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

• Stratégies de support AKS
• FAQ du support Azure

Fonctionnement d’un cluster isolé du réseau

Le diagramme suivant montre la communication réseau entre les dépendances d’un cluster AKS isolé du réseau.

Les clusters AKS extraient les images nécessaires au cluster et à ses fonctionnalités ou modules complémentaires à partir du Registre des artefacts Microsoft (MAR). Cette extraction d’image permet à AKS de fournir les dernières versions des composants du cluster, et de corriger également les failles de sécurité critiques. Un cluster isolé du réseau tente d’extraire ces images d’une instance privée d’Azure Container Registry (ACR) connectée au cluster au lieu de les extraire de MAR. Si les images ne sont pas présentes, l’instance d’ACR privée les extrait de MAR, et les met à disposition via son point de terminaison privé, ce qui évite d’activer la sortie du cluster vers le point de terminaison MAR public.

Les options suivantes sont prises en charge pour une instance d’ACR privée avec des clusters isolés du réseau :

• ACR géré par AKS - AKS crée, gère et synchronise une ressource ACR dans cette option. Vous n’avez pas besoin d’affecter d’autorisations ou de gérer l’instance d’ACR. AKS gère les règles de mise en cache, la liaison privée et le point de terminaison privé utilisés dans le cluster isolé du réseau. Une instance d’ACR gérée par AKS suit le même comportement que les autres ressources (table de routage, groupes de machines virtuelles identiques Azure, etc.) dans le groupe de ressources d’infrastructure. Pour éviter tout risque d’échec des composants du cluster ou du démarrage d’un nouveau nœud, ne mettez pas à jour ou ne supprimez pas l’instance d’ACR, ses règles de mise en cache ou ses images système.. L’instance d’ACR gérée par AKS est synchronisée en permanence pour que les composants du cluster et les nouveaux nœuds fonctionnent comme prévu.

  Remarque

  Une fois que vous avez supprimé un cluster AKS isolé du réseau, les ressources associées telles que l’instance d’ACR gérée par AKS, la liaison privée et le point de terminaison privé sont automatiquement supprimées.

• BYO (Apportez votre propre) ACR - L’option BYO ACR nécessite la création d’une instance d’ACR avec une liaison privée entre la ressource ACR et le cluster AKS. Consultez Connexion privée à un registre de conteneurs Azure à l’aide d’Azure Private Link afin de comprendre comment configurer un point de terminaison privé pour votre registre.

  Remarque

  Quand vous supprimez le cluster AKS, la fonctionnalité BYO ACR, la liaison privée et le point de terminaison privé ne sont pas supprimés automatiquement. Si vous ajoutez des images et des règles de mise en cache personnalisées à la fonctionnalité BYO ACR, celles-ci sont conservées après la synchronisation du cluster, après la désactivation de la fonctionnalité ou après la suppression du cluster AKS.

Quand vous créez un cluster AKS isolé du réseau, vous pouvez choisir l’un des modes de cluster privé suivants :

• Cluster AKS basé sur une liaison privée - Le plan de contrôle ou le serveur d’API se trouve dans un groupe de ressources Azure géré par AKS, et votre pool de nœuds se trouve dans votre groupe de ressources. Le serveur et le pool de nœuds peuvent communiquer entre eux via le service Azure Private Link dans le réseau virtuel du serveur d’API, et via un point de terminaison privé exposé dans le sous-réseau de votre cluster AKS.
• Intégration au réseau virtuel du serveur d’API (préversion) - Un cluster configuré avec l’intégration au réseau virtuel du serveur d’API projette le point de terminaison de serveur d’API directement dans un sous-réseau délégué du réseau virtuel où AKS est déployé. L’intégration au réseau virtuel du serveur d’API permet une communication réseau entre le serveur d’API et les nœuds du cluster sans qu’il soit nécessaire d’utiliser un tunnel ni une liaison privée.

Limites

• Les clusters isolés du réseau sont pris en charge sur les clusters AKS utilisant Kubernetes version 1.30 ou une version ultérieure.
• Seul le canal NodeImage de mise à niveau automatique des images du système d’exploitation de nœud est pris en charge pour les clusters isolés du réseau
• Les pools de nœuds Windows ne sont pas pris en charge pour le moment.
• Les extensions de cluster AKS suivantes ne sont pas encore prises en charge sur les clusters isolés du réseau :
  • Dapr
  • Azure App Configuration
  • Azure Machine Learning
  • Flux (GitOps)
  • Stockage de conteneur Azure
  • Sauvegarde Azure pour AKS

Forum aux questions

Quelle est la différence entre un cluster isolé du réseau et le Pare-feu Azure ?

Un cluster isolé du réseau ne nécessite aucun trafic de sortie au-delà du VNet (réseau virtuel) tout au long du processus de démarrage du cluster. Un cluster isolé du réseau a le type de trafic sortant none ou block. Si le type de trafic sortant a la valeur none, AKS ne configure aucune connexion sortante pour le cluster, ce qui permet à l’utilisateur de les configurer lui-même. Si le type de trafic sortant a la valeur block, toutes les connexions sortantes sont bloquées.

Un pare-feu établit généralement un cloisonnement entre un réseau approuvé et un réseau non approuvé, tel qu’Internet. Le Pare-feu Azure, par exemple, peut restreindre le trafic HTTP et HTTPS sortant en fonction du nom de domaine complet de la destination, ce qui vous donne un contrôle de trafic de sortie affiné, tout en vous permettant d’accéder aux noms de domaine complets englobant les dépendances sortantes d’un cluster AKS (ce que les groupes de sécurité réseau ne peuvent pas faire). Par exemple, vous pouvez définir le type de trafic sortant du cluster à userDefinedRouting pour forcer le trafic sortant à passer par le pare-feu, puis configurer des restrictions de FQDN sur le trafic sortant.

En résumé, bien que le Pare-feu Azure puisse être utilisé pour définir des restrictions de sortie sur les clusters ayant des requêtes sortantes, les clusters isolés du réseau vont plus loin dans la posture sécurisée par défaut en éliminant ou en bloquant complètement les requêtes sortantes.

Dois-je configurer des points de terminaison de liste d’autorisation pour que le cluster isolé du réseau fonctionne ?

Les phases de création et de démarrage du cluster ne nécessitent aucun trafic sortant en provenance du cluster isolé du réseau. Les images nécessaires aux composants et modules complémentaires AKS sont extraites de l’instance d’ACR privée connectée au cluster au lieu d’être extraites du Registre des artefacts Microsoft (MAR) via des points de terminaison publics.

Une fois que vous avez configuré un cluster isolé du réseau, si vous souhaitez activer des fonctionnalités ou des modules complémentaires qui doivent effectuer des requêtes sortantes vers leurs points de terminaison de service, vous pouvez configurer des points de terminaison privés vers les services fonctionnant avec Azure Private Link.

Puis-je mettre à niveau manuellement des packages pour mettre à niveau l’image du pool de nœuds ?

La mise à niveau manuelle des packages en fonction de la sortie vers les référentiels de packages n’est pas prise en charge. À la place, vous pouvez effectuer une mise à niveau automatique des images de système d’exploitation de nœuds. Seul le canal de mise à niveau automatique de système d’exploitation de nœud NodeImage est pris en charge pour les clusters isolés du réseau.

Étapes suivantes

• Créer un cluster isolé du réseau