Contrôler le trafic réseau depuis HDInsight sur les pools et clusters de cluster AKS
Important
Cette fonctionnalité est disponible actuellement en mode Aperçu. Les Conditions d’utilisation supplémentaires pour les préversions de Microsoft Azure contiennent davantage de conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou ne se trouvant pas encore en disponibilité générale. Pour plus d’informations sur cette préversion spécifique, consultez les Informations sur la préversion d’Azure HDInsight sur AKS. Pour toute question ou pour des suggestions à propos des fonctionnalités, veuillez envoyer vos requêtes et leurs détails sur AskHDInsight, et suivez-nous sur la Communauté Azure HDInsight pour plus de mises à jour.
HDInsight sur AKS est une 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 que Apache Spark™, Apache Flink®️ et Trino sans les frais généraux liés à la gestion et à la surveillance des conteneurs.
Par défaut, les clusters HDInsight sur AKS autorisent les connexions réseau sortantes depuis les clusters vers n’importe quelle destination, si la destination est accessible depuis l’interface réseau du nœud. Cette autorisation signifie que les ressources de cluster peuvent accéder à n’importe quelle adresse IP publique ou privée, n’importe quel 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 pouvez :
Empêchez 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.
Analysez 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 de différentes options et différents outils pour gérer la façon dont le trafic de sortie circule depuis 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.
Sortant avec équilibreur de charge. Lorsque vous déployez un pool de clusters avec ce chemin Sortie, une adresse IP publique est approvisionnée et affectée à la ressource d’équilibreur de charge. Un réseau virtuel personnalisé (VNET) n’est pas obligatoire, mais il est fortement recommandé. Vous pouvez utiliser le Pare-feu Azure ou des groupes de sécurité réseau (NSG) sur le VNET 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 Sortie, l’utilisateur peut gérer le trafic de sortie au niveau du sous-réseau à l’aide du Pare-feu Azure / de la passerelle NAT et de tables de routage personnalisées. Cette option est disponible uniquement lors de l’utilisation d’un VNET personnalisé.
Activer AKS privé. Lorsque vous activez AKS privé sur votre pool de clusters, le serveur d’API AKS se voit attribuer une adresse IP interne et n’est pas accessible publiquement. Le trafic réseau entre le serveur d’API AKS et les pools de nœuds HDInsight sur AKS (clusters) reste sur le réseau privé.
Cluster avec entrée privée. 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 des clients du même VNET. Vous devez fournir votre propre solution NAT, telle qu’une passerelle NAT, ou la traduction d’adresses réseau (NAT) fournie par votre pare-feu, pour vous connecter à des dépendances HDInsight sur AKS publiques sortantes.
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 la sortie via l’adresse IP publique attribuée par HDInsight sur AKS. Lorsque vous configurez le type de sortie d’équilibreur de charge sur votre pool de clusters, vous pouvez vous attendre à une sortie de l’équilibreur de charge créé par HDInsight sur AKS.
Vous pouvez configurer la sortie avec la configuration de l’équilibreur de charge à l’aide du Portail Azure.
Une fois que vous avez opté pour cette configuration, HDInsight sur AKS crée automatiquement une adresse IP publique approvisionnée pour la sortie du cluster et les attributions à la ressource de l’équilibreur de charge.
Une IP publique créée par HDInsight sur AKS, et c’est une ressource gérée par AKS, ce qui signifie qu’AKS gère le cycle de vie de cette 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 demandes au cluster, vous devez établir une liste d’autorisation pour le trafic. Vous pouvez également configurer certaines règles dans le groupe de sécurité réseau pour effectuer un contrôle à gros grains.
Sortant avec routage défini par l’utilisateur
Remarque
Le type 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 la sortie doit être effectuée par l’utilisateur.
Vous devez déployer le cluster HDInsight sur AKS dans un réseau virtuel existant avec un sous-réseau qui a été préalablement configuré, et vous devez établir une sortie explicite.
Cette architecture requiert l’envoi explicite du trafic sortant vers une appliance comme un pare-feu, une passerelle ou un proxy, pour qu’une adresse IP publique attribué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 ni de règle 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 sortant.
Pour le trafic entrant, vous êtes obligé de choisir selon vos besoins un cluster privé (pour sécuriser le trafic sur le plan de contrôle / le serveur d’API AKS) et de sélectionner l’option d’entrée privée disponible sur chacune des formes de cluster pour utiliser le trafic public ou interne basé sur l’équilibreur de charge.
Création d’un pool de clusters pour sortie avec userDefinedRouting
Lorsque vous utilisez des pools de clusters HDInsight sur AKS et choisissez userDefinedRouting (UDR) comme chemin de sortie, aucun équilibreur de charge standard n’est approvisionné. Vous devez configurer les règles de pare-feu pour les ressources sortantes avant que userDefinedRouting ne puisse fonctionner.
Important
Le chemin de sortie UDR requiert un itinéraire pour 0.0.0.0/0 et une destination du tronçon suivant de votre pare-feu ou NVA dans la table de routage. La table de routage contient déjà une valeur par défaut 0.0.0.0/0 vers 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 l’itinéraire 0.0.0.0/0 que vous créez ne pointe pas vers Internet, mais vers une passerelle, une NVA, etc. Quand vous utilisez un itinéraire défini par l’utilisateur, une adresse IP publique d’équilibreur de charge pour les demandes entrantes est créée seulement si vous configurez un service de type loadbalancer. HDInsight sur AKS ne crée jamais d’adresse IP publique pour les demandes sortantes quand vous utilisez un type de sortie UDR.
Avec les étapes suivantes, vous allez comprendre comment verrouiller le trafic sortant de votre service HDInsight sur AKS vers les ressources Azure back-end ou autres ressources réseau avec le Pare-feu Azure. Cette configuration permet d’empêcher l’exfiltration de données ou le risque d’implantation de programmes malveillants.
Pare-feu Azure vous permet de contrôler le trafic sortant à un niveau beaucoup plus granulaire et de filtrer le trafic en fonction du renseignement sur les menaces fourni en temps réel par Microsoft Cyber Security. Vous pouvez créer, appliquer et consigner des stratégies de connectivité réseau et d’application de façon centralisée entre les abonnements et les 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.
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 un nom de votre choix.
Dans le portail Azure, accédez au réseau virtuel intégré à votre application.
Dans le volet de navigation de gauche, sélectionnez Sous-réseaux > + Sous-réseau.
Dans Nom, entrez AzureFirewallSubnet.
Dans Plage d’adresses de sous-réseau, acceptez la valeur par défaut ou spécifiez une plage d’au moins /26.
Sélectionnez Enregistrer.
Déployer le pare-feu et obtenir son adresse IP
Dans le menu du Portail Azure ou dans la page Accueil, sélectionnez Créer une ressource.
Saisissez pare-feu dans la zone de recherche et appuyez sur Entrée.
Sélectionnez Pare-feu, puis Créer.
Sur la page Créer un pare-feu, configurez le pare-feu comme indiqué dans le tableau suivant :
Paramètre 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 une 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. 
Cliquez sur Vérifier + créer.
Sélectionnez Créer à nouveau. Ce processus de déploiement prend quelques minutes.
Une fois le déploiement terminé, accédez à votre groupe de ressources et sélectionnez le pare-feu.
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 d’acheminement pour le réseau virtuel.
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 y ajoute les itinéraires par défaut du système. 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 vous l’associez au sous-réseau App Service dans le réseau virtuel intégré.
Dans le menu Portail Azure, sélectionnez Tous les services ou recherchez et sélectionnez Tous les services dans n’importe quelle page.
Sous Mise en réseau, sélectionnez Tables d’itinéraires.
Sélectionnez Ajouter.
Configurez la table de routage comme dans l’exemple suivant :
Veillez à sélectionner la même région que le pare-feu que vous avez créé.
Sélectionnez Revoir + créer.
Sélectionnez Create (Créer).
Une fois le déploiement terminé, sélectionnez Accéder à la ressource.
Dans le menu de navigation de gauche, sélectionnez Itinéraires> Ajouter.
Configurez le nouvel itinéraire comme indiqué dans le tableau suivant :
Paramètre Valeur Type de destination Adresses IP Plages d’adresses IP/CIDR de destination 0.0.0.0/0 Type de tronçon suivant Appliance virtuelle adresse de tronçon suivant Adresse IP privée du pare-feu que vous avez copié Dans le volet de navigation de gauche, sélectionnez Sous-réseaux> Associer.
Dans Réseau virtuel, sélectionnez votre réseau virtuel intégré.
Dans Sous-réseau, sélectionnez le sous-réseau HDInsight sur AKS que vous souhaitez utiliser.
Cliquez sur OK.
Configurer les stratégies de pare-feu
Le trafic sortant de votre sous-réseau HDInsight sur 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.
Accédez à la page de présentation du pare-feu et sélectionnez sa stratégie de pare-feu.
Dans la page de stratégie de pare-feu, dans la navigation de gauche, ajoutez des règles de réseau et d’application. Par exemple, sélectionnez Règles de réseau > Ajouter une collection de règles.
Dans Règles, ajoutez une règle réseau avec le sous-réseau comme adresse source et spécifiez une destination FQDN. De même, ajoutez les règles d’application.
- Vous devez ajouter les règles de trafic sortant fournies ici. Reportez-vous ce document pour ajouter des règles d’application et de réseau pour autoriser le trafic du cluster à fonctionner. (AKS ApiServer doit être ajouté après la création du clusterPool car vous ne pouvez obtenir l’AKS ApiServer qu’après avoir créé le clusterPool).
- 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 (exemple – stockage).
Sélectionnez Ajouter.
Vérifier si l’adresse IP publique est créée
Une fois 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 le Outbound with userDefinedRouting chemin egress, vous devez donner au cluster AKS – qui correspond au pool de clusters – le Network Contributor rôle sur vos ressources réseau qui sont utilisées pour définir le routage, telles que le réseau virtuel, la table des routes et le NSG (si utilisé). Pour en savoir plus sur l’attribution du rôle, cliquez ici
Remarque
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 FQDN pour accéder au cluster.
Création d’un pool de clusters avec AKS privé
Dans un cluster privé, le plan de contrôle ou le serveur d’API dispose d’adresses IP internes qui sont définies dans le document RFC1918 - document Address Allocation for Private Internet. En utilisant cette option d’AKS privé, vous pouvez garantir le trafic réseau entre votre serveur d’API et vos clusters de charge de travail HDInsight sur AKS uniquement sur le réseau privé.
Quand vous provisionnez un cluster AKS privé, AKS crée par défaut un FQDN privé avec une zone DNS privée et un FQDN 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é afin de résoudre l’adresse IP privée du point de terminaison privé pour la communication avec le serveur d’API.
HDInsight sur AKS insère automatiquement l’enregistrement dans la zone DNS privée dans le groupe managé créé HDInsight sur AKS, pour l’entrée privée.
Clusters avec entrée privée
Lorsque vous créez un cluster avec HDInsight sur AKS, celui-ci a un FQDN public et une adresse IP publique auxquels 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.
Remarque
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 un accès Internet public au cluster. Le cluster bénéficie d’un équilibreur de charge interne et d’une adresse IP privée. HDInsight sur AKS utilise la zone DNS privée que le pool de clusters a créée pour connecter le réseau virtuel de cluster et effectuer une résolution de noms.
Chaque cluster privé contient deux FQDN : le FQDN public et le FQDN privé.
FQDN public : {clusterName}.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
Le FQDN public peut uniquement être résolu en CNAME avec un sous-domaine, c’est pourquoi il doit être utilisé avec la Private DNS zone setting appropriée pour vous assurer que le FQDN peut être résolu en adresse IP privée appropriée.
La zone DNS privée doit pouvoir résoudre le FQDN privé en IP (privatelink.{clusterPoolName}.{subscriptionId}).
Remarque
HDInsight sur AKS crée une zone DNS privée dans le pool de clusters, réseau virtuel. Si vos applications client se trouvent dans le même réseau virtuel, vous n’avez pas besoin de reconfigurer la zone DNS privée. Si vous utilisez une application cliente dans un autre réseau virtuel, vous devez utiliser l’appairage de réseaux virtuels et établir une liaison à la 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. Vous pouvez également utiliser des zones DNS privées pour ajouter l’enregistrement A à l’adresse IP privée du point de terminaison privé.
FQDN privé : {clusterName}.privatelink.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
Le FQDN 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 est résolu en adresse IP privée du cluster.
Référence
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour