Contrôler le trafic réseau à partir de HDInsight sur les pools et clusters de cluster AKS

Important

Azure HDInsight sur AKS a été mis hors service le 31 janvier 2025. En savoir plus avec cette annonce.

Vous devez migrer vos charges de travail vers Microsoft Fabric ou un produit Azure équivalent pour éviter l’arrêt brusque de vos charges de travail.

Important

Cette fonctionnalité est actuellement en préversion. Les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure incluent des termes juridiques supplémentaires qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale. Pour plus d’informations sur cette préversion spécifique, consultez informations sur Azure HDInsight sur AKS en préversion. Pour des questions ou des suggestions de fonctionnalités, envoyez une demande sur AskHDInsight avec les détails et suivez-nous pour plus de mises à jour sur Communauté Azure HDInsight.

HDInsight sur AKS est une plateforme managée en tant que service (PaaS) qui s’exécute sur Azure Kubernetes Service (AKS). HDInsight sur AKS vous permet de déployer des charges de travail Open-Source Analytics populaires telles qu’Apache Spark™, Apache Flink®️ et Trino sans surcharge de gestion et de surveillance des conteneurs.

Par défaut, HDInsight sur les clusters AKS autorise les connexions réseau sortantes de clusters à n’importe quelle destination, si la destination est accessible à partir de l’interface réseau du nœud. Cela signifie que les ressources de cluster peuvent accéder à n’importe quelle adresse IP publique ou privée, nom de domaine ou URL sur Internet ou sur votre réseau virtuel.

Toutefois, dans certains scénarios, vous pouvez contrôler ou restreindre le trafic de sortie de votre cluster pour des raisons de sécurité et de conformité.

Par exemple, vous souhaiterez peut-être :

• Empêcher les clusters d’accéder aux services malveillants ou indésirables.

• Appliquez des stratégies réseau ou des règles de pare-feu sur le trafic sortant.

• Surveillez ou auditez le trafic de sortie du cluster à des fins de résolution des problèmes ou de conformité.

Méthodes et outils pour contrôler le trafic de sortie

Vous disposez d’options et d’outils différents pour gérer la façon dont le trafic de sortie circule à partir de HDInsight sur des clusters AKS. Vous pouvez configurer certains d’entre eux au niveau du pool de clusters et d’autres au niveau du cluster.

• Sortie avec équilibreur de charge. Lorsque vous déployez un pool de clusters avec ce chemin d’accès de sortie, une adresse IP publique est provisionnée et affectée à la ressource d’équilibreur de charge. Un réseau virtuel personnalisé (VNET) n’est pas obligatoire ; toutefois, il est fortement recommandé. Vous pouvez utiliser le Pare-feu Azure ou les groupes de sécurité réseau (NSG) sur le réseau virtuel personnalisé pour gérer le trafic qui quitte le réseau.

• Sortant avec routage défini par l’utilisateur. Lorsque vous déployez un pool de clusters avec ce chemin d’accès de sortie, l’utilisateur peut gérer le trafic de sortie au niveau du sous-réseau à l’aide du Pare-feu Azure / passerelle NAT et des tables de routage personnalisées. Cette option est disponible uniquement lors de l’utilisation d’un réseau virtuel personnalisé.

• Activez AKS privé. Lorsque vous activez AKS privé sur votre pool de clusters, le serveur d’API AKS reçoit une adresse IP interne et n’est pas accessible publiquement. Le trafic réseau entre le serveur d’API AKS et HDInsight sur les pools de nœuds AKS (clusters) reste sur le réseau privé.

• Cluster d’entrée privé. Lorsque vous déployez un cluster avec l’option d’entrée privée activée, aucune adresse IP publique n’est créée et le cluster n’est accessible qu’à partir de clients au sein du même réseau virtuel. Vous devez fournir votre propre solution NAT, telle qu’une passerelle NAT ou une NAT fournie par votre pare-feu, pour vous connecter à des dépendances HDInsight publiques et sortantes sur AKS.

Dans les sections suivantes, nous décrivons chaque méthode en détail.

Sortant avec équilibreur de charge

L'équilibreur de charge est utilisé pour le trafic sortant par une adresse IP publique assignée par HDInsight sur AKS. Lorsque vous configurez le type d'équilibreur de charge de sortie sur votre pool de clusters, vous pouvez vous attendre à ce que la sortie soit gérée par l’équilibreur de charge créé par HDInsight sur AKS.

Vous pouvez configurer le trafic sortant avec la configuration de l’équilibreur de charge à l’aide du portail Azure.

Une fois que vous avez choisi cette configuration, HDInsight sur AKS termine automatiquement la création d’une adresse IP publique provisionnée pour la sortie de cluster & affectée à la ressource d’équilibreur de charge.

Une adresse IP publique créée par HDInsight sur AKS et une ressource gérée par AKS, ce qui signifie qu’AKS gère le cycle de vie de cette adresse IP publique et ne nécessite pas d’action de l’utilisateur directement sur la ressource IP publique.

Lorsque des clusters sont créés, certaines adresses IP publiques d’entrée sont également créées.

Pour autoriser l’envoi de requêtes au cluster, vous devez mettre le trafic sur la liste d'autorisation. Vous pouvez également configurer certaines règles dans le NSG pour effectuer un contrôle grossier.

Sortant avec routage défini par l’utilisateur

Remarque

Le type de trafic sortant userDefinedRouting est un scénario de mise en réseau avancé et nécessite une configuration réseau appropriée avant de commencer.
La modification du type sortant après la création du pool de clusters n’est pas prise en charge.

Si userDefinedRouting est défini, HDInsight sur AKS ne configure pas automatiquement les chemins de sortie. La configuration de sortie doit être effectuée par l’utilisateur.

capture d’écran

Vous devez déployer HDInsight sur un cluster AKS dans un réseau virtuel existant avec un sous-réseau précédemment configuré, et vous devez établir une sortie explicite.

Cette architecture nécessite l’envoi explicite du trafic de sortie à une appliance telle qu’un pare-feu, une passerelle ou un proxy, afin qu’une adresse IP publique affectée à l’équilibreur de charge standard ou à l’appliance puisse gérer la traduction d’adresses réseau (NAT).

HDInsight sur AKS ne configure pas d’adresse IP publique sortante ou de règles de trafic sortant, contrairement aux clusters de type Sortant avec équilibreur de charge, comme décrit dans la section ci-dessus. Votre UDR est la seule source de trafic de sortie.

Pour le trafic entrant, vous devez choisir en fonction des conditions requises pour choisir un cluster privé (pour sécuriser le trafic sur le plan de contrôle AKS /serveur d’API) et sélectionner l’option d’entrée privée disponible sur chaque forme de cluster pour utiliser le trafic public ou interne basé sur l’équilibreur de charge.

Création d’un pool de clusters pour le trafic sortant avec userDefinedRouting

Lorsque vous utilisez HDInsight sur des pools de clusters AKS et choisissez userDefinedRouting (UDR) comme chemin d’accès de sortie, aucun équilibreur de charge standard n’est provisionné. Vous devez configurer les règles de pare-feu pour les ressources sortantes avant de pouvoir fonctionner userDefinedRouting.

Important

Le chemin de sortie UDR nécessite un itinéraire pour 0.0.0.0/0 ainsi qu'un saut suivant vers votre pare-feu ou votre appliance virtuelle de réseau dans la table de routage. La table de routage a déjà une valeur par défaut 0.0.0.0/0 sur Internet. Vous ne pouvez pas obtenir de connectivité Internet sortante en ajoutant simplement cet itinéraire, car Azure a besoin d’une adresse IP publique pour SNAT. AKS vérifie que vous ne créez pas d’itinéraire 0.0.0.0/0 pointant vers Internet, mais vers une passerelle, une appliance virtuelle réseau, etc. Lorsque vous utilisez UDR, une adresse IP publique de l’équilibreur de charge pour les requêtes entrantes est créée uniquement si vous configurez un service de type loadbalancer. HDInsight sur AKS ne crée jamais d’adresse IP publique pour les requêtes sortantes lorsque vous utilisez un chemin de sortie UDR.

capture d’écran

Avec les étapes suivantes, vous allez comprendre comment verrouiller le trafic sortant de votre service HDInsight sur AKS vers des ressources Azure principales ou d’autres ressources réseau avec le Pare-feu Azure. Cette configuration permet d’éviter l’exfiltration des données ou le risque d’implantation de programmes malveillants.

Le Pare-feu Azure vous permet de contrôler le trafic sortant à un niveau beaucoup plus précis et de filtrer le trafic en fonction du renseignement sur les menaces en temps réel de Microsoft Cyber Security. Vous pouvez créer, appliquer et journaliser des stratégies de connectivité réseau et d’application au sein des abonnements et des réseaux virtuels.

Voici un exemple de configuration des règles de pare-feu et de test de vos connexions sortantes

Voici un exemple de configuration des règles de pare-feu et de vérification de vos connexions sortantes.

1. Créer le sous-réseau de pare-feu requis

   Pour déployer un pare-feu dans le réseau virtuel intégré, vous avez besoin d’un sous-réseau appelé AzureFirewallSubnet ou nom de votre choix.

   1. Dans le portail Azure, accédez au réseau virtuel intégré à votre application.

   2. Dans le volet de navigation gauche, sélectionnez Sous-réseaux > + Sous-réseau.

   3. Dans Nom, tapez AzureFirewallSubnet.

   4. Plage d’adresses de sous-réseau, acceptez la valeur par défaut ou spécifiez une plage d'une taille d'au moins /26.

   5. Sélectionnez Enregistrer.

2. Déployer le pare-feu et obtenir son adresse IP

   1. Dans le menu du portail Azure ou dans la page Accueil, sélectionnez Créer une ressource.

   2. Tapez le pare-feu dans la zone de recherche, puis appuyez sur Entrée.

   3. Sélectionnez pare-feu, puis sélectionnez Créer.

   4. Dans la page Créer un pare-feu, configurez le pare-feu comme indiqué dans le tableau suivant :

      Réglage	Valeur
      Groupe de ressources	Même groupe de ressources que le réseau virtuel intégré.
      Nom	Nom de votre choix
      Région	Même région que le réseau virtuel intégré.
      Stratégie de pare-feu	Créez-en un en sélectionnant Ajouter nouveau.
      Réseau virtuel	Sélectionnez le réseau virtuel intégré.
      Adresse IP publique	Sélectionnez une adresse existante ou créez-en une en sélectionnant Ajouter nouveau.

      capture d’écran

   5. Cliquez sur Vérifier + créer.

   6. Sélectionnez Créer à nouveau. Ce processus prend quelques minutes à déployer.

   7. Une fois le déploiement terminé, accédez à votre groupe de ressources, puis sélectionnez le pare-feu.

   8. Dans la page Vue d’ensemble du pare-feu, copiez l’adresse IP privée. L’adresse IP privée sera utilisée comme adresse de tronçon suivant dans la règle de routage du réseau virtuel.

      

3. Acheminer tout le trafic vers le pare-feu

   Lorsque vous créez un réseau virtuel, Azure crée automatiquement une table de routage par défaut pour chacun de ses sous-réseaux et ajoute des itinéraires système par défaut à la table. Dans cette étape, vous créez une table de routage définie par l’utilisateur qui achemine tout le trafic vers le pare-feu, puis l’associez au sous-réseau App Service dans le réseau virtuel intégré.

   1. Dans le menu du portail Azure, sélectionnez Tous les services ou recherchez et sélectionnez Tous les services dans n’importe quelle page.

   2. Sous Mise en réseau, sélectionnez Tables de routage.

   3. Sélectionnez Ajouter.

   4. Configurez la table de routage comme l’exemple suivant :

      

      Veillez à sélectionner la même région que le pare-feu que vous avez créé.

   5. Sélectionnez Vérifier + créer.

   6. Sélectionnez Créer.

   7. Une fois le déploiement terminé, sélectionnez Accéder à la ressource.

   8. Dans le volet de navigation de gauche, sélectionnez Routes > Ajouter.

   9. Configurez le nouvel itinéraire, comme indiqué dans le tableau suivant :

      Réglage	Valeur
      Type de Destination	Adresses IP
      Adresses IP de destination/plages CIDR	0.0.0.0/0
      Type de saut suivant	Appliance virtuelle
      Adresse du tronçon suivant	Adresse IP privée du pare-feu que vous avez copié

   10. Dans le volet de navigation gauche, sélectionnez Sous-réseaux > Associer.

   11. Dans réseau virtuel, sélectionnez votre réseau virtuel intégré.

   12. Dans sous-réseau, sélectionnez HDInsight sur le sous-réseau AKS que vous souhaitez utiliser.

       

   13. Sélectionnez OK.

4. Configurer des stratégies de pare-feu

   Le trafic sortant de votre hdInsight sur un sous-réseau AKS est désormais acheminé via le réseau virtuel intégré vers le pare-feu. Pour contrôler le trafic sortant, ajoutez une règle d’application à la stratégie de pare-feu.

   1. Accédez à la page de vue d’ensemble du pare-feu et sélectionnez sa stratégie de pare-feu.

   2. Dans la page de stratégie de pare-feu, à partir de la navigation de gauche, ajoutez des règles de réseau et d’application. Par exemple, sélectionnez règles réseau > Ajouter une collection de règles.

   3. Dans Règles, ajoutez une règle réseau avec le sous-réseau comme adresse source et spécifiez une destination de nom de domaine complet. De même, ajoutez les règles d’application.

      1. Vous devez ajouter les règles de trafic sortant fournies ici. Reportez-vous au document référencé par pour ajouter des règles d'application et de réseau afin de permettre au cluster de fonctionner correctement. (AKS ApiServer doit être ajouté une fois le clusterPool créé, car vous pouvez uniquement obtenir AKS ApiServer après avoir créé le clusterPool).
      2. Vous pouvez également ajouter les points de terminaison privés pour toutes les ressources dépendantes du même sous-réseau pour que le cluster y accède (par exemple, stockage).

   4. Sélectionnez Ajouter.

5. Vérifier si l’adresse IP publique est créée

Avec les règles de pare-feu définies, vous pouvez sélectionner le sous-réseau lors de la création du pool de clusters.

Une fois le pool de clusters créé, vous pouvez observer dans le groupe MC qu’aucune adresse IP publique n’est créée.

Important

Avant de créer le cluster dans la configuration du pool de clusters avec Outbound with userDefinedRouting chemin d’accès de sortie, vous devez donner au cluster AKS - qui correspond au pool de clusters - le rôle Network Contributor sur vos ressources réseau utilisées pour définir le routage, comme le réseau virtuel, la table de routage et le groupe de sécurité réseau (le cas échéant). En savoir plus sur l’attribution du rôle ici

Note

Lorsque vous déployez un pool de clusters avec un chemin de sortie UDR et un cluster d'entrée privé, HDInsight sur AKS crée automatiquement une zone DNS privée et mappe les entrées afin de résoudre le nom de domaine pleinement qualifié pour accéder au cluster.

Création d’un pool de clusters avec AKS privé

Avec AKS privé, le plan de contrôle ou le serveur d’API a des adresses IP internes définies dans le RFC1918 - Allocation d’adresses pour le document Internet privé. En utilisant cette option d’AKS privé, vous pouvez garantir que le trafic réseau entre votre serveur d’API et vos clusters de charge de travail HDInsight sur AKS reste uniquement sur le réseau privé.

Lorsque vous approvisionnez un cluster AKS privé, AKS crée par défaut un nom de domaine complet privé avec une zone DNS privée et un nom de domaine complet public supplémentaire avec un enregistrement A correspondant dans le DNS public Azure. Les nœuds d’agent continuent d’utiliser l’enregistrement dans la zone DNS privée pour résoudre l’adresse IP privée du point de terminaison privé pour la communication avec le serveur d’API.

Comme HDInsight sur AKS insère automatiquement l’enregistrement dans la zone DNS privée du groupe géré créé par HDInsight sur AKS pour un accès privé.

Clusters avec accès privé

Lorsque vous créez un cluster avec HDInsight sur AKS, il a un nom de domaine complet public et une adresse IP auxquelles tout le monde peut accéder. Avec la fonctionnalité d’entrée privée, vous pouvez vous assurer que seul votre réseau privé peut envoyer et recevoir des données entre le client et le cluster HDInsight sur AKS.

Capture d’écran

Note

Avec cette fonctionnalité, HDInsight sur AKS crée automatiquement des enregistrements A sur la zone DNS privée pour l’entrée.

Cette fonctionnalité empêche l’accès Internet public au cluster. Le cluster obtient un équilibreur de charge interne et une adresse IP privée. HDInsight sur AKS utilise la zone DNS privée que le pool de clusters a créé pour connecter le réseau virtuel de cluster et effectuer une résolution de noms.

Chaque cluster privé contient deux noms de domaine complets : le nom de domaine complet public et le nom de domaine complet privé.

Nom de domaine complet public : {clusterName}.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net

Le nom de domaine complet public ne peut être résolu qu’en CNAME avec un sous-domaine. Par conséquent, il doit être utilisé avec la Private DNS zone setting correcte pour vous assurer que le nom de domaine complet peut enfin être résolu pour corriger l’adresse IP privée.

La zone DNS privée doit être en mesure de résoudre le FQDN privé en adresse IP (privatelink.{clusterPoolName}.{subscriptionId}).

Note

HDInsight sur AKS crée une zone DNS privée dans le pool de clusters, réseau virtuel. Si vos applications clientes se trouvent dans le même réseau virtuel, vous n’avez pas besoin de configurer à nouveau la zone DNS privée. Si vous utilisez une application cliente dans un autre réseau virtuel, vous devez utiliser le peering de réseaux virtuels et établir une liaison à une zone dns privée dans le réseau virtuel du pool de clusters ou utiliser des points de terminaison privés dans le réseau virtuel et des zones dns privées pour ajouter l’enregistrement A à l’adresse IP privée du point de terminaison privé.

Nom de domaine complet privé : {clusterName}.privatelink.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net

Le nom de domaine complet privé est attribué aux clusters avec l’entrée privée activée uniquement. Il s’agit d’un enregistrement A dans la zone DNS privée qui pointe vers l’adresse IP privée du cluster.

Référence

• Commencer avec les clusters privés sur HDInsight et AKS pour sécuriser vos tâches d'analyse.

• routage du trafic sur le réseau virtuel Azure.

• Peering de réseau virtuel Azure.

• trafic sortant sur HDInsight sur AKS - Azure HDInsight sur AKS

• Règles de réseau sortant et FQDN pour les clusters Azure Kubernetes Service (AKS) - Azure Kubernetes Service.