Configurer le trafic réseau sortant pour les clusters Azure HDInsight à l’aide du pare-feu

Article
10/01/2024

Cet article décrit les étapes de sécurisation du trafic sortant de votre cluster HDInsight à l’aide du pare-feu Azure. Les étapes ci-dessous supposent que vous configurez le Pare-feu Azure d’un cluster existant. Si vous déployez un nouveau cluster derrière un pare-feu, créez d’abord votre cluster HDInsight et votre sous-réseau. Suivez ensuite les étapes décrites dans ce guide.

Arrière-plan

Les clusters HDInsight sont normalement déployés dans un réseau virtuel. Le cluster a des dépendances vis-à-vis de services en dehors de ce réseau virtuel.

Le trafic de gestion entrant ne peut pas être envoyé via un pare-feu. Vous pouvez utiliser les balises du service NSG pour le trafic entrant comme indiqué ici.

Les dépendances de trafic sortant HDInsight sont presque entièrement définies avec des FQDN, qui n’ont pas d’adresses IP statiques sous-jacentes. L’absence d’adresses statiques signifie que les groupes de sécurité réseau (NSG) ne peuvent pas verrouiller le trafic sortant d’un cluster. Les adresses IP changent suffisamment souvent pour qu’il ne soit pas possible de définir des règles basées sur la résolution de noms actuelle et de les utiliser.

Sécurisez les adresses sortantes à l’aide d’un pare-feu qui peut contrôler le trafic sortant en fonction des FQDN. Le Pare-feu Azure restreint le trafic sortant en fonction du FQDN de la destination ou des balises FQDN.

Configuration du pare-feu Azure avec HDInsight

Voici le résumé des étapes pour verrouiller les sorties de votre cluster HDInsight existant avec le pare-feu Azure :

Créez un sous-réseau.
Créez un pare-feu.
règles Add application du pare-feu.
Ajoutez des règles de réseau au pare-feu.
Créez une table de routage.

Créer un sous-réseau

Créez un sous-réseau nommé AzureFirewallSubnet dans le réseau virtuel où se trouve votre cluster.

Créer un pare-feu pour votre cluster

Créez un pare-feu nommé Test-FW01 à l’aide des étapes décrites dans Déployer le pare-feu, dans Tutoriel : Déployer et configurer un pare-feu Azure à l’aide du portail Azure

Configurer le pare-feu avec des règles d’application

Créez un regroupement de règles d’application permettant au cluster d’envoyer et de recevoir les communications importantes.

Sélectionnez le nouveau pare-feu Test-FW01 dans le Portail Azure.
Accédez à Paramètres>Règles>Collection de règles d’application>+ Add application rule collection.

Sur l’écran Add application rule collection, fournissez les informations suivantes :

Section supérieure

Propriété	Valeur
Nom	FwAppRule
Priority	200
Action	Allow

Section des étiquettes FQDN

Nom	Adresse source	Balise FQDN	Notes
Rule_1	*	WindowsUpdate et HDInsight	Requis pour les services HDI

Section des noms de domaine complets cibles

Nom	Adresses sources	Protocole : Port	Noms de domaine complets cibles	Notes
Rule_2	*	https:443	login.windows.net	Autorise les activités de connexion Windows
Rule_3	*	https:443	login.microsoftonline.com	Autorise les activités de connexion Windows
Rule_4	*	https:443	storage_account_name.blob.core.windows.net	Remplacez `storage_account_name` par votre nom de compte de stockage réel. Veillez à ce que l’option « Transfert sécurisé requis » soit activée sur le compte de stockage. Si vous utilisez un point de terminaison privé pour accéder aux comptes de stockage, cette étape n’est pas nécessaire et le trafic de stockage n’est pas transféré vers le pare-feu.
Rule_5	*	http:80	azure.archive.ubuntu.com	Autorise l’installation des correctifs de sécurité Ubuntu sur le cluster
Rule_6	*	https:433	pypi.org, pypi.python.org, files.pythonhosted.org	Autorise les installations de packages Python pour la surveillance d’Azure

Titre : Entrer les détails de la collection de règles d’application.

Sélectionnez Ajouter.

Configurer le pare-feu avec des règles de réseau

Créez les règles de réseau pour configurer correctement votre cluster HDInsight.

Après l’étape précédente, accédez à Ajouter une collection de règles de réseau>+ Add network rule collection.

Sur l’écran Add network rule collection, fournissez les informations suivantes :

Section supérieure

Propriété	Valeur
Nom	FwNetRule
Priority	200
Action	Allow

Section des étiquettes de service

Nom	Protocol	Adresses sources	Étiquettes de service	Ports de destination	Notes
Rule_6	TCP	*	SQL	1433, 11000-11999	Si vous utilisez les serveurs SQL par défaut fournis par HDInsight, configurez une règle de réseau dans la section Balises de service pour SQL qui vous permettra de consigner et d’auditer le trafic SQL. Si vous avez configuré des points de terminaison de service pour SQL Server sur le sous-réseau HDInsight, le pare-feu sera contourné. Si vous utilisez un serveur SQL personnalisé pour Ambari, Oozie, Ranger et le metastore Hive, vous devez uniquement autoriser le trafic vers vos propres serveurs SQL personnalisés. Consultez Architecture de connectivité Azure SQL Database et Azure Synapse Analytics pour voir pourquoi la plage de ports 11000-11999 est nécessaire en plus du port 1433.
Rule_7	TCP	*	Azure Monitor	*	(facultatif) Les clients qui envisagent d’utiliser la fonctionnalité de mise à l’échelle automatique doivent ajouter cette règle.

Title : Entrer une collection de règles d’application.

Sélectionnez Ajouter.

Créer et configurer une table de routage

Créez une table de routage avec les entrées suivantes :

Toutes les adresses IP de Services de gestion et d’intégrité avec le type de tronçon suivant Internet. Elle doit inclure 4 adresses IP des régions génériques et 2 adresses IP pour votre région spécifique. Cette règle est requise uniquement si ResourceProviderConnection est défini sur Entrant. Si ResourceProviderConnection est défini sur Outbound (Sortant), ces adresses IP ne sont pas nécessaires dans l’UDR.
Une route d’appliance virtuelle pour l’adresse IP 0.0.0.0/0 avec comme tronçon suivant l’adresse IP privée de votre pare-feu Azure.

Par exemple, pour configurer la table de routage d’un cluster créé dans la région des États-Unis « USA Est », procédez comme suit :

Sélectionnez votre pare-feu Azure Test-FW01. Copiez l’adresse IP privée figurant dans la page Vue d’ensemble. Pour cet exemple, nous utiliserons un exemple d’adresse 10.0.2.4.
Accédez ensuite à Tous les services>Mise en réseau>Tables de routage et Créer une table de routage.
À partir de votre nouvelle route, accédez à Paramètres>Routes>+ Ajouter. Ajoutez les routes suivantes :

Nom de l’itinéraire	Préfixe de l’adresse	Type de tronçon suivant	adresse de tronçon suivant
168.61.49.99	168.61.49.99/32	Internet	N/D
23.99.5.239	23.99.5.239/32	Internet	N/D
168.61.48.131	168.61.48.131/32	Internet	N/D
138.91.141.162	138.91.141.162/32	Internet	N/D
13.82.225.233	13.82.225.233/32	Internet	N/D
40.71.175.99	40.71.175.99/32	Internet	N/D
0.0.0.0	0.0.0.0/0	Appliance virtuelle	10.0.2.4

Terminez la configuration de la table de routage :

Affectez la table de routage que vous avez créée à votre sous-réseau HDInsight en sélectionnant Sous-réseaux sous Paramètres.
Sélectionnez + Associer.
Dans l’écran Associer un sous-réseau, sélectionnez le réseau virtuel dans lequel votre cluster a été créé et le sous-réseau que vous avez utilisé pour votre cluster HDInsight.
Sélectionnez OK.

Nœud de périphérie ou trafic d’application personnalisée

Les étapes ci-dessus permettent à votre cluster de fonctionner sans problème. Vous devez encore configurer les dépendances pour prendre en charge vos applications personnalisées s’exécutant sur les nœuds de périphérie, le cas échéant.

Les dépendances des applications doivent être identifiées et ajoutées au pare-feu Azure ou à la table de routage.

Les itinéraires doivent être créés pour le trafic des applications afin d’éviter des problèmes de routage asymétrique.

Si vos applications ont d’autres dépendances, celles-ci doivent être ajoutées à votre pare-feu Azure. Créez des règles d’application pour autoriser le trafic HTTP/HTTPS et des règles de réseau pour tout le reste.

Journalisation et mise à l’échelle

Le pare-feu Azure peut envoyer des journaux à plusieurs systèmes de stockage différents. Pour obtenir des instructions sur la configuration de la journalisation de votre pare-feu, suivez les étapes décrites dans l’article Didacticiel : superviser les journaux du Pare-feu Azure et les métriques.

Une fois que vous avez terminé la configuration de la journalisation, si vous utilisez Log Analytics, vous pouvez afficher le trafic bloqué à l’aide d’une requête, par exemple :

AzureDiagnostics | where msg_s contains "Deny" | where TimeGenerated >= ago(1h)

L’intégration de Pare-feu Azure aux journaux d’activité d’Azure Monitor est utile lors de la première utilisation d’une application, en particulier lorsque vous ne connaissez pas toutes les dépendances de l’application. Pour en savoir plus sur les journaux d’activité Azure Monitor, consultez Analyser les données de journal d’activité dans Azure Monitor

Pour en savoir plus sur les limites de mise à l’échelle du Pare-feu Azure et demander une augmentation, consultez ce document ou reportez-vous au FAQ.

Accès au cluster

Après avoir correctement configuré le pare-feu, vous pouvez utiliser le point de terminaison interne (https://CLUSTERNAME-int.azurehdinsight.net) pour accéder à l’API Ambari à partir du réseau virtuel.

Pour utiliser le point de terminaison public (https://CLUSTERNAME.azurehdinsight.net) ou ssh (CLUSTERNAME-ssh.azurehdinsight.net), assurez-vous d’avoir les routes appropriées dans la table de routage et les règles de groupe de sécurité réseau pour éviter le problème de routage asymétrique expliqué ici. Plus précisément, dans ce cas, vous devez autoriser l’adresse IP du client dans les règles NSG entrantes et l’ajouter à la table de routage définie par l’utilisateur avec le tronçon suivant défini comme internet. Si le routage n’est pas configuré correctement, une erreur d’expiration du délai s’affiche.

Partager via