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

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) standard disposent d’un accès Internet sortant illimité. 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 le réseau sortant et les règles de nom de domaine complet (FQDN) pour les clusters AKS fournit une liste des points de terminaison requis pour le cluster AKS et ses modules complémentaires et fonctionnalités facultatifs.

Une solution courante pour restreindre le trafic sortant du cluster consiste à utiliser un appareil de pare-feu pour restreindre le trafic en fonction des règles de pare-feu. Le pare-feu s’applique lorsque votre application requiert un accès sortant, mais lorsque les demandes sortantes doivent être inspectées et sécurisées. La configuration manuelle d’un pare-feu avec les règles de sortie requises et les FQDN est un processus fastidieux, en particulier si vous devez uniquement créer un cluster AKS isolé sans dépendances sortantes pour le démarrage du cluster.

Pour réduire le risque d’exfiltration des données, le cluster isolé réseau permet de démarrer le cluster AKS sans dépendances réseau sortantes, même pour extraire des composants/images de cluster à partir de Microsoft Artifact Registry (MAR). L’opérateur de cluster peut configurer de manière incrémentielle le trafic sortant autorisé pour chaque scénario qu’il souhaite activer.

Fonctionnement d’un cluster isolé du réseau

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

Les clusters AKS récupèrent les artefacts requis pour le cluster et ses fonctionnalités ou modules complémentaires à partir du Registre d’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é de réseau tente d’extraire ces images et fichiers binaires à partir d’une instance Azure Container Registry (ACR) privée connectée au cluster au lieu d’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 deux options suivantes sont prises en charge pour un ACR privé associé à des clusters isolés réseau :

• ACR géré par AKS - AKS crée, gère et synchronise une ressource ACR dans cette option. Il n’y a rien à faire.

  Remarque

  La ressource ACR gérée par AKS est créée dans votre abonnement. Si vous supprimez le cluster dont l'ACR est managé par AKS pour la source d’artefacts d’amorçage. Les ressources associées telles que l’ACR géré par AKS, la liaison privée et le point de terminaison privé sont également supprimées automatiquement. Si vous changez le type de sortie sur un cluster pour un type autre que none ou block avec --bootstrap-artifact-source conservé en tant que Cache. Ensuite, les ressources associées ne sont pas 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. Vous devez également attribuer des autorisations et gérer les règles de cache, la liaison privée et le point de terminaison privé utilisés dans le cluster.

  Remarque

  Lorsque vous supprimez le cluster AKS ou après avoir désactivé la fonctionnalité. L’ACR BYO, la liaison privée et le point de terminaison privé ne sont pas supprimés automatiquement. Si vous ajoutez des images personnalisées et des règles de cache à BYO ACR, elles persistent après le rapprochement du cluster.

Pour créer un cluster isolé réseau, vous devez d’abord vous assurer que le trafic réseau entre votre serveur d’API et vos pools de nœuds reste uniquement sur le réseau privé, vous pouvez choisir l’un des modes de cluster privé suivants :

• Cluster basé sur des liaisons privées : 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.
• Cluster configuré pour l’intégration au réseau virtuel du serveur d’API : un cluster configuré avec l’intégration au réseau virtuel du serveur d’API projette le point de terminaison du serveur d’API directement dans un sous-réseau délégué dans le 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.

Vous devez également vous assurer que le chemin de sortie de votre cluster AKS est contrôlé et limité. Vous pouvez choisir l’un des types de sortie réseau suivants :

• Type de sortie de none – Si none est défini. AKS ne configure pas automatiquement les chemins d’accès de sortie et un itinéraire par défaut n’est pas obligatoire. Il est pris en charge dans les scénarios de réseau virtuel BYO (bring-your-own) et les scénarios de réseau virtuel managé. Pour mettre en place votre propre scénario de réseau virtuel, vous devez établir des chemins de sortie explicites si nécessaire.
• Le type sortant de block (préversion) -If block est défini. AKS configure les règles réseau pour bloquer activement tout le trafic de sortie du cluster. Cette option est utile pour les environnements hautement sécurisés où la connectivité sortante doit être restreinte. Il est pris en charge dans le scénario de réseau virtuel managé. Vous pouvez également obtenir un effet similaire en bloquant tout le trafic de sortie en ajoutant des règles de groupe de sécurité réseau (NSG) avec none dans le scénario de réseau virtuel bring-your-own.

Limites

• Unmanaged le canal n’est pas pris en charge.
• Les pools de nœuds Windows ne sont pas encore pris en charge.
• La mise en réseau kubenet n’est pas prise en charge.

Utilisation de fonctionnalités, de modules complémentaires et d’extensions nécessitant une sortie

Pour les clusters isolés du réseau avec BYO ACR :

• Si vous souhaitez utiliser une fonctionnalité AKS ou un plug-in qui nécessite un accès réseau sortant dans des clusters isolés réseau avec un type réseau sortant none, ce document contient les exigences réseau sortantes pour chaque fonctionnalité. Ce document énumère également les fonctionnalités ou modules complémentaires qui prennent en charge l’intégration de liaison privée pour une connexion sécurisée à partir du réseau virtuel du cluster. Il est recommandé de configurer des points de terminaison privés pour accéder à ces fonctionnalités. Par exemple, vous pouvez configurer l’ingestion basée sur un point de terminaison privé pour utiliser Managed Prometheus (espace de travail Azure Monitor) et Container Insights (espace de travail Log Analytics) dans des clusters isolés du réseau. Si une intégration de liaison privée n’est pas disponible pour l’une de ces fonctionnalités. Vous pouvez ensuite configurer le cluster avec une table de routage définie par l’utilisateur et un pare-feu Azure en fonction des règles réseau et des règles d’application requises pour cette fonctionnalité.
• Si vous utilisez le pilote CSI (Container Storage Interface) Azure pour Azure Files et le stockage Blob, vous devez créer une classe de stockage personnalisée avec « networkEndpointType : privateEndpoint », consultez des exemples dans les classes de stockage Azure Files et les classes de stockage Blob Azure.
• Les extensions de cluster AKS suivantes ne sont pas encore prises en charge sur les clusters isolés du réseau :
  • Dapr
  • Configuration d'application Azure
  • Azure Machine Learning
  • Flux (GitOps)
  • 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é de réseau a un type sortant soit none soit 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 est défini sur 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 les trafics HTTP et HTTPS sortants en fonction de la destination. Cette solution vous permet de contrôler avec précision le trafic de sortie, tout en vous donnant accès aux noms de domaine complets qui englobent les dépendances sortantes d’un cluster AKS. Il s’agit d'une tâche que les groupes de sécurité réseau ne peuvent pas accomplir. 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. Il existe de nombreux cas où vous souhaitez toujours un pare-feu. Par exemple, vous disposez d’un trafic sortant de toute façon à partir de votre application ou que vous souhaitez contrôler, inspecter et sécuriser le trafic du cluster à la fois de sortie et d’entrée.

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.

Après avoir configuré un cluster isolé réseau. Si vous souhaitez activer des fonctionnalités ou des modules complémentaires qui doivent effectuer des demandes sortantes vers leurs points de terminaison de service, vous pouvez configurer des points de terminaison privés sur les services alimentés par 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 recommandée. Au lieu de cela, vous pouvez mettre à niveau manuellement ou mettre à niveau automatiquement vos images de système d'exploitation de nœud. NodeImage et None sont les seuls canaux de mise à niveau actuellement pris en charge pour les clusters isolés réseau.

Que se passe-t-il si je modifie le type sortant autre que none ou block, est-ce que cela fait toujours un cluster isolé du réseau ?

Les seuls types sortants pris en charge pour un cluster isolé réseau sont les types none et block. Si vous utilisez un autre type de sortie, le cluster peut toujours extraire des artefacts de l’ACR privé associé. Toutefois, cette opération peut générer un trafic de sortie.

Étapes suivantes

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