Protection de l’accès sortant de l’espace de travail pour les charges de travail d’ingénierie des données

La protection de l’accès sortant de l’espace de travail permet un contrôle précis des communications externes à partir d’espaces de travail Microsoft Fabric. Lorsque cette fonctionnalité est activée, les éléments de l’espace de travail d’ingénierie des données, tels que les notebooks, les définitions de travaux Spark et les lakehouses, ne sont pas autorisés à établir des connexions sortantes à des points de terminaison publics, sauf si l’accès est explicitement accordé par le biais de points de terminaison privés managés approuvés. Cette fonctionnalité est cruciale pour les organisations dans des environnements sécurisés ou réglementés, car elle permet d’empêcher l’exfiltration des données et d’appliquer les limites du réseau organisationnel.

Compréhension de la protection de l'accès sortant avec l'ingénierie des données

Lorsque la protection d’accès sortant est activée, toutes les connexions sortantes de l’espace de travail sont bloquées par défaut. Les administrateurs d’espace de travail peuvent ensuite créer des exceptions pour accorder l’accès uniquement aux destinations approuvées en configurant des points de terminaison privés managés :

Configuration de la protection d’accès sortant pour l’ingénierie des données

Pour configurer la protection d’accès sortant pour l’ingénierie des données :

1. Suivez les étapes pour activer la protection d’accès sortant.

2. Après avoir activé la protection d’accès sortant, vous pouvez configurer des points de terminaison privés managés pour autoriser l’accès sortant à d’autres espaces de travail ou ressources externes en fonction des besoins.

Une fois configurés, les éléments d’ingénierie des données ne peuvent se connecter qu’aux points de terminaison privés managés approuvés, tandis que toutes les autres connexions sortantes restent bloquées.

Types d’éléments d’ingénierie de données pris en charge

Les types d’éléments d’ingénierie des données suivants bénéficient de la protection d’accès sortant :

• Maisons au bord du lac
• Notebooks
• Définitions de travaux Spark
• Environments

Les sections suivantes expliquent comment la protection d’accès sortant affecte des types d’éléments d’ingénierie de données spécifiques dans votre espace de travail.

Notebooks

Lorsque la protection d’accès sortant est activée sur un espace de travail, les notebooks peuvent référencer une destination uniquement si un point de terminaison privé managé est configuré de l’espace de travail vers la destination.

Présentation du comportement du chemin d’accès aux fichiers dans les notebooks Fabric

Lorsque vous accédez à des données dans votre Lakehouse à partir d’un notebook Fabric, vous pouvez faire référence à des fichiers à l’aide de chemins relatifs ou complets (absolus). Comprendre les différences est importante pour réussir l’accès aux données, en particulier lors de l’utilisation d’espaces de travail.

Chemins relatifs

Les chemins relatifs sont le moyen le plus simple et le plus courant de référencer des fichiers dans votre lakehouse actuel. Lorsque vous faites glisser et déposez un fichier de l’explorateur Lakehouse dans une cellule de bloc-notes, un chemin relatif est utilisé automatiquement.

Exemple :
Files/people.csv

Code Spark :

df = spark.read.format("csv").option("header", "true").load("Files/people.csv")

Les chemins relatifs fonctionnent immédiatement et ne nécessitent aucune autre configuration.

Chemins complets (absolus)

Les chemins entièrement qualifiés spécifient l’emplacement complet d’un fichier, y compris l’espace de travail et les informations Lakehouse. Toutefois, l’utilisation de noms d’affichage dans ces chemins peut entraîner des erreurs, telles que les délais d’expiration du socket, car la session Spark ne peut pas les résoudre par défaut.

Exemple incorrect (échouera) :
abfss://your_workspace@onelake.dfs.fabric.microsoft.com/your_lakehouse.Lakehouse/Files/people.csv

Accès aux données entre les espaces de travail

Pour accéder aux fichiers d'un Lakehouse situé dans un autre espace de travail, utilisez un chemin complet qui inclut l'ID de l'espace de travail et l'ID du Lakehouse (et non leurs noms d'affichage). Cela garantit que Spark peut résoudre le chemin d’accès et accéder aux données.

Format d’URI correct :
abfss://<workspace_id>@onelake.dfs.fabric.microsoft.com/<lakehouse_id>/Files/people.csv

Exemple de code Spark :

df = spark.read.format("csv").option("header", "true").load("abfss://4c8efb42-7d2a-4a87-b1b1-e7e98bea053d@onelake.dfs.fabric.microsoft.com/5a0ffa3d-80b9-49ce-acd2-2c9302cce6b8/Files/people.csv")

Comment trouver les identifiants d’espace de travail et de lakehouse

• ID de l’espace de travail : Le GUID après /groups/ dans l’URL de votre espace de travail Fabric.
• ID Lakehouse : Le GUID qui suit /lakehouses/ dans l’URL.

Exemple d’URL :
https://app.fabric.microsoft.com/groups/4c8efb42-7d2a-4a87-b1b1-e7e98bea053d/lakehouses/5a0ffa3d-80b9-49ce-acd2-2c9302cce6b8/...

Tâches Spark

Lorsque la protection d’accès sortant de l’espace de travail est activée, les clusters Spark ne peuvent pas établir de connexions sortantes à l’Internet public. Cela inclut les éléments suivants :

• Installation de packages Python directement à partir de PyPI à l’aide de pip install
• Accès à des domaines publics tels que https://login.microsoftonline.com
• Connexion à toutes les API ou sites web externes

Microsoft Fabric applique cette restriction via des réseaux virtuels managés (réseaux virtuels managés), qui isolent les clusters Spark des réseaux externes, sauf si l’accès explicite est accordé.

Sécuriser la connectivité avec des points de terminaison privés managés

Pour permettre aux clusters Spark de se connecter à des ressources externes tout en conservant la sécurité, vous devez utiliser des points de terminaison privés managés. Ces points de terminaison autorisent les connexions sécurisées et approuvées à :

• Services externes (par exemple, Azure SQL Database, Stockage Blob Azure)
• Autres espaces de travail Fabric au sein du même locataire

Seules les connexions établies via des points de terminaison privés managés approuvés sont autorisées. Toutes les autres tentatives d’accès sortantes sont bloquées par défaut.

Installation sécurisée de bibliothèques dans des espaces de travail protégés par accès sortant

Étant donné que Fabric bloque le trafic Internet public, les clusters Spark ne peuvent pas installer directement des packages à partir de PyPI à l’aide pip installde .

Vous disposez de deux options sécurisées pour installer des bibliothèques dans un espace de travail avec la protection d’accès sortant activée :

1. Chargez et utilisez des fichiers wheel : Préparez manuellement les fichiers de roue de package Python requis sur une ressource de calcul approuvée, puis chargez-les dans votre environnement Fabric. Cette méthode garantit que seuls les packages approuvés sont installés et évitent l’accès à Internet public.

2. Héberger un miroir PyPI privé : Configurez un référentiel PyPI privé sur Stockage Azure et synchronisez-le avec les packages sélectionnés à partir de l’index PyPI public. Configurez votre environnement Fabric pour installer des packages à partir de ce miroir privé à l’aide de points de terminaison privés managés, en maintenant la conformité avec les stratégies de sécurité réseau.

Choisissez l’approche qui convient le mieux aux exigences de votre organisation pour la gestion des packages et la sécurité.

Option 1 : Charger et utiliser des fichiers de roue

1. Identifiez les packages manquants non inclus dans le runtime Fabric Spark.

2. Exécutez le script suivant sur votre ressource de calcul pour configurer un environnement Python local identique au runtime Microsoft Fabric Spark 1.3. Ce script nécessite un fichier YAML contenant une liste de toutes les bibliothèques incluses dans l’environnement prébaked.

3. Vérifiez que les bibliothèques privées hébergées par Microsoft sont supprimées de ce YAML.

   wget https://repo.anaconda.com/miniconda/Miniconda3-py310_24.1.2-0-Linux-x86_64.sh 
   bash Miniconda3-py310_24.1.2-0-Linux-x86_64.sh 
   chmod 755 -R /usr/lib/miniforge3/ 
   export PATH="/usr/lib/miniforge3/bin:$PATH" 
   sudo apt-get update 
   sudo apt-get -yq install gcc g++ 
   conda env create -n <custom-env-name> -f Python<version>-CPU.yml 
   source activate <custom-env-name> 
   

4. Le script peut être utilisé pour passer votre fichier requirements.txt, qui contient tous les packages et versions que vous envisagez d’installer dans le runtime Spark. Il imprime les noms des nouveaux fichiers/dépendances wheel pour les exigences de votre bibliothèque d’entrée.

   pip install -r <input-user-req.txt> > pip_output.txt 
   cat pip_output.txt | grep "Using cached *" 
   

5. Téléchargez .whl les fichiers manuellement.

6. Utilisez l’artefact d’environnement pour charger toutes les roues requises.

7. Attachez l’environnement aux blocs-notes ou aux travaux.

Option 2 : Héberger un miroir PyPI privé sur stockage Azure

Prerequisites

• Ressources de calcul, telles qu’une machine de développement Linux, un sous-système Windows pour Linux (WSL) ou une machine virtuelle Azure.
  • Exemple : Démarrage rapide - Créer une machine virtuelle Linux dans le portail Azure - Machines virtuelles Azure.
• Compte de stockage Azure pour stocker les packages mis en miroir.
  • Créez un compte de stockage - Stockage Azure.
• Utilitaires:
  • Bandersnatch : outil de mise en miroir PyPI pour la synchronisation des référentiels. Consultez la documentation bandersnatch.
  • Azure CLI, Blobfuse2 ou AzCopy : Utilitaires pour le chargement et la synchronisation de fichiers avec Stockage Azure.

Synchronisation initiale du référentiel PyPI

À titre d’étape initiale, vous devez effectuer une synchronisation du référentiel PyPI. Le référentiel PyPI complet contient un grand nombre de packages et est en constante expansion, ce qui permet au téléchargement initial de prendre entre 8 et 48 heures, en fonction de votre matériel et de votre réseau. Pour connaître la taille actuelle du référentiel et le nombre de packages, reportez-vous aux statistiques · PyPI.

Maintenance

La surveillance et les mises à jour périodiques sont requises pour maintenir le miroir synchronisé. Les facteurs suivants affectent la vitesse de synchronisation :

• Vitesse du réseau.
• Ressources serveur telles que l’UC, la mémoire et les E/S de disque sur la ressource de calcul exécutant Bandersnatch.
• La vitesse de disque (SSD et HDD) a un impact sur la rapidité avec laquelle Bandersnatch écrit des données.
• Configuration initiale et synchronisation de maintenance : la synchronisation initiale télécharge l’intégralité du référentiel et peut prendre entre 8 et 48 heures, mais les synchronisations suivantes sont plus rapides, car elles mettent à jour uniquement les packages nouveaux ou modifiés.

Étapes de configuration

1. Configurez une machine virtuelle Linux ou un sous-système Windows pour un ordinateur de développement Linux (WSL)..

   wget https://repo.anaconda.com/miniconda/Miniconda3-py310_24.1.2-0-Linux-x86_64.sh 
   bash Miniconda3-py310_24.1.2-0-Linux-x86_64.sh 
   chmod 755 -R /usr/lib/miniforge3/ 
   
   # Add Python executable to PATH 
   export PATH="/usr/lib/miniforge3/bin:$PATH" 
   

2. Installez Bandersnatch pour mettre en miroir PyPI. Bandersnatch est un outil de mise en miroir PyPI qui télécharge l’ensemble du référentiel PyPI et les fichiers d’index associés sur le système de fichiers local.

   # Install Bandersnatch 
   pip install bandersnatch
   

3. Configurer Bandersnatch : créez un fichier bandersnatch.conf avec les configurations spécifiées dans l’exemple sur GitHub sur bandersnatch/src/bandersnatch/example.conf.

4. Exécutez une commande miroir pour effectuer une synchronisation ponctuelle avec le serveur principal PyPI.

   bandersnatch --config <path-to-bandersnatch.conf> mirror

   Cette commande crée les sous-répertoires suivants dans votre répertoire miroir sur le système de fichiers local.

   Note

   La synchronisation initiale prend du temps à s’exécuter (reportez-vous aux statistiques · PyPI). Bandersnatch prend également en charge la mise en miroir sélective à l’aide de plug-ins de liste d'autorisation et de liste de blocage, ce qui permet de gérer les dépendances plus efficacement. En filtrant les packages inutiles, vous pouvez réduire la taille du miroir, ce qui réduit les coûts et les efforts de maintenance. Par exemple, si le miroir est destiné uniquement à Fabric, vous pouvez exclure des fichiers binaires Windows pour optimiser le stockage. Nous vous recommandons d’évaluer ces options de filtrage en fonction de votre cas d’usage.

   Consultez également la documentation sur le filtrage miroir - Bandersnatch.

5. Pour vérifier la configuration du miroir, vous pouvez utiliser un serveur HTTP pour servir votre miroir PyPI local. Cette commande démarre un serveur HTTP simple sur le port 8000 qui sert le contenu du répertoire miroir :

   cd <directory-to-mirror>
   python -m http.server 8000
   

6. Configurez pip pour utiliser le miroir PyPI local :

   pip install <package> -index-url http://localhost:8000/simple 
   

7. Chargez le miroir sur le compte de stockage et sélectionnez Activer le site web statique sur votre compte de stockage Azure. Ce paramètre vous permet d’héberger du contenu statique comme PyPI la page d’index. L’activation de ce paramètre génère automatiquement un conteneur nommé $web.

   Vous pouvez utiliser Azure CLI ou AzCopy de blobfuse2 pour charger le miroir local à partir de votre ordinateur de développement vers votre compte de stockage Azure.

   • Chargez le dossier packages dans votre conteneur choisi sur le conteneur de compte de stockage.
   • Chargez des dossiers JSON simples, PyPI, local-stats et JSON dans $web conteneur de votre compte de stockage.

8. Pour utiliser ce miroir dans votre élément d’environnement Fabric, créez deux points de terminaison privés managés dans Fabric :

   • Un pour le conteneur d’objets blob (packages)
   • Un pour le site web statique (index)

9. Utilisez l’artefact d’environnement pour spécifier un fichier yml pour installer la gestion des bibliothèques dans les environnements Fabric.

   dependencies: 
     - pip 
     - pip: 
       - pytest==8.2.2 
       - --index-url https://<storage-account-name>.z5.web.core.windows.net/simple 
   

10. Vous pouvez également installer des packages directement dans un notebook à l’aide de la %pip install commande :

   %pip install pytest --index-url https://<storage-account-name>.z5.web.core.windows.net/simple

Schémas Lakehouse et protection d’accès sortant

Les lakehouses qui utilisent des schémas sont entièrement pris en charge lorsqu'ils sont accessibles à partir de composants au sein du même espace de travail, notamment lorsque la protection d’accès sortant est activée.

Dans les scénarios d’accès inter-espaces de travail, le comportement diffère selon la façon dont Lakehouse est accessible lorsque la protection d’accès sortant est activée sur l’espace de travail consommateur.

Scénarios pris en charge

• Les éléments de producteur et de consommateur se trouvent dans le même espace de travail
• Lakehouse utilise des schémas
• L’accès est effectué à l’aide des API basées sur spark DataFrame

Dans ces scénarios, les opérations de schéma Lakehouse fonctionnent comme prévu.

Comportement inter-espaces de travail avec la protection d’accès sortant activée

Lorsque la protection d’accès sortant est activée sur un espace de travail et qu’un lakehouse avec schéma est accessible à partir d’un autre espace de travail, le comportement suivant s’applique :

• ✅ L’accès à l’aide des API DataFrame Spark (par exemple, la lecture de tables dans des DataFrames) continue de fonctionner
• ❌ L’accès à l’aide d’instructions Spark SQL peut échouer.

Par exemple, spark.read.table() réussit, tandis que SELECT * FROM table peut échouer dans les scénarios entre-espaces de travail lorsque la protection d'accès sortante est activée.

Comprendre le comportement des chemins d’accès aux fichiers

Lorsque vous utilisez des données dans votre lakehouse à l’aide d’un notebook Fabric, vous pouvez référencer des fichiers de deux manières principales :

• Si votre espace de travail dispose d’une protection d’accès sortant activée, il utilise des réseaux virtuels managés (VNET) pour Spark. Dans ce cas, les pools de démarrage sont désactivés et vous devez vous attendre à ce que les sessions Spark prennent 3 à 5 minutes.

• Avec la protection d’accès sortant, l’accès public à partir de Spark est bloqué. Cette restriction empêche les utilisateurs de télécharger des bibliothèques directement à partir de canaux publics tels que PyPI à l’aide de pip. Pour installer des bibliothèques pour leurs travaux d’ingénierie des données, les utilisateurs ont deux options (pour plus d’informations, consultez Installation sécurisée des bibliothèques dans les espaces de travail protégés par accès sortant) :

  • Packages de bibliothèque de référence à partir d’une source de données connectée à l’espace de travail Fabric via un point de terminaison privé managé.

  • Téléchargez les fichiers Wheel pour leurs bibliothèques et dépendances requises (qui ne sont pas déjà inclus dans le runtime prédéfini).

• L’activation de la protection d’accès sortant bloque l’accès public à partir de votre espace de travail. Par conséquent, pour interroger un Lakehouse à partir d’un autre espace de travail, vous devez créer un point de terminaison privé géré par plusieurs espaces de travail pour permettre aux travaux Spark d’établir une connexion.

• L’utilisation de chemins complets avec des noms d’espace de travail et lakehouse peut entraîner une exception de délai d’expiration du socket. Pour accéder aux fichiers, utilisez des chemins relatifs pour le Lakehouse actuel ou utilisez un chemin complet qui inclut l’ID d’espace de travail et l’ID du Lakehouse (et non leurs noms affichés). Cette approche garantit que la session Spark peut résoudre correctement le chemin d’accès et éviter les erreurs de délai d’expiration du socket. En savoir plus.

Contenu connexe

• Vue d’ensemble de la protection d’accès sortant de l’espace de travail
• Configurer la protection d’accès sortant de l’espace de travail