Gérer les stratégies réseau pour le contrôle de sortie serverless

Cette page explique comment configurer et gérer des stratégies réseau pour contrôler les connexions réseau sortantes à partir de vos charges de travail serverless dans Azure Databricks.

Pour le contrôle d’entrée, consultez le contrôle d’entrée basé sur le contexte.

Spécifications

• Votre espace de travail Azure Databricks doit se trouver au niveau Premium.

• Les autorisations de gestion des stratégies réseau sont limitées aux administrateurs de compte.

Accès aux stratégies réseau

Pour créer, afficher et mettre à jour des stratégies réseau dans votre compte :

1. Dans la console de compte, cliquez sur Sécurité.
2. Cliquez sur l’onglet Mise en réseau .
3. Sous Stratégies, cliquez sur Contrôle d’entrée et de sortie basé sur le contexte.

Créer une stratégie réseau

1. Cliquez sur Créer une stratégie réseau.

2. Entrez un nom de stratégie.

3. Cliquez sur l’onglet Sortie .

   Pour définir des règles d’entrée, consultez Définir des règles d’entrée.

4. Choisissez un mode d’accès réseau :

   • Autoriser l’accès à toutes les destinations : accès Internet sortant illimité. Si vous choisissez Accès complet, l’accès Internet sortant reste illimité.
   • Accès restreint à des destinations spécifiques : l’accès sortant est limité aux destinations spécifiées.

Configurer des stratégies réseau

Les étapes suivantes décrivent les paramètres facultatifs pour le mode d’accès restreint.

Définir des règles de sortie

Avant de définir des règles de sortie, notez :

• Lorsque vous utilisez un compartiment S3 dans votre metastore, vous devez utiliser l’API REST pour ajouter explicitement le compartiment à votre liste d’autorisation de sortie pour que l’accès réussisse.
• Le nombre maximal de destinations prises en charge est de 2500.
• Le nombre de noms de domaine complets pouvant être ajoutés en tant que domaines autorisés est limité à 100 par stratégie.

• Les domaines ajoutés en tant qu’entrées Private Link pour un équilibreur de charge sont implicitement autorisés dans les stratégies réseau. Lorsqu’un domaine est supprimé ou que le point de terminaison privé est supprimé, il peut prendre jusqu’à 24 heures pour que les contrôles de stratégie réseau appliquent entièrement la modification. Consultez Configurer la connectivité privée aux ressources de votre réseau virtuel.
• Les compartiments de partage delta sont implicitement autorisés dans les stratégies réseau.

1. Pour accorder à votre calcul serverless l’accès à des domaines supplémentaires, cliquez sur Ajouter une destination au-dessus de la liste des Domaines autorisés.

   

   Le filtre FQDN permet d’accéder à tous les domaines qui partagent la même adresse IP. Le service de modèle approvisionné dans les points de terminaison empêche l’accès à Internet quand l’accès réseau est restreint. Toutefois, le contrôle granulaire avec le filtrage FQDN n’est pas pris en charge.

2. Pour permettre à votre espace de travail d’accéder à des comptes de stockage Azure supplémentaires, cliquez sur le bouton Ajouter une destination au-dessus de la liste des destinations de stockage autorisées .

   

Mise en œuvre des politiques

Le mode exécution sèche vous permet de tester la configuration de votre stratégie et de surveiller les connexions sortantes sans interrompre l’accès aux ressources. Lorsque le mode d’exécution sèche est activé, les demandes qui violent la stratégie sont journalisées, mais pas bloquées. Vous pouvez sélectionner l’une des options suivantes :

1. Databricks SQL: les entrepôts Databricks SQL fonctionnent en mode de fonctionnement sec.

2. Service de modèle IA : les points de terminaison de service de modèle fonctionnent en mode d’exécution sèche.

3. Tous les produits: tous les services Azure Databricks fonctionnent en mode exécution sèche, en remplaçant toutes les autres sélections.

   

Mettre à jour la stratégie par défaut

Chaque compte Azure Databricks inclut une stratégie par défaut . La stratégie par défaut est associée à tous les espaces de travail sans affectation de stratégie réseau explicite, y compris les espaces de travail nouvellement créés. Vous pouvez modifier cette stratégie, mais elle ne peut pas être supprimée.

Les stratégies par défaut sont appliquées uniquement aux espaces de travail avec au moins le niveau Premium.

Associer une stratégie réseau aux espaces de travail

Si vous avez mis à jour votre stratégie par défaut avec des configurations supplémentaires, elles sont automatiquement appliquées aux espaces de travail qui n’ont pas de stratégie réseau existante.

Votre espace de travail doit être au niveau Premium.

Pour associer votre espace de travail à une autre stratégie, procédez comme suit :

1. Sélectionnez un espace de travail.
2. Dans Politique de réseau, cliquez sur Mettre à jour la politique de réseau.
3. Sélectionnez la stratégie réseau souhaitée dans la liste.
4. Cliquez sur Appliquer une stratégie.

Appliquer des modifications de stratégie réseau

La plupart des mises à jour de configuration réseau se propagent automatiquement à votre calcul serverless en dix minutes. notamment :

• Ajout d’un nouvel emplacement ou d’une connexion externe du catalogue Unity.
• Attachement de votre espace de travail à un autre metastore.
• Modification du stockage autorisé ou des destinations Internet.

Redémarrer ou redéployer des charges de calcul sans serveur

Vous devez uniquement effectuer une mise à jour lors du basculement du mode d’accès à Internet ou lors de la mise à jour du mode d’exécution à sec.

Pour déterminer la procédure de redémarrage appropriée, reportez-vous à la liste suivante par produit :

• Service Databricks ML : redéployez votre point de terminaison de service ML. Consultez Créer des points de terminaison pour des modèles personnalisés
• Pipelines : arrêtez puis redémarrez vos pipelines déclaratifs Spark Lakeflow en cours d’exécution. Consultez Exécuter une mise à jour de pipeline.
• l’entrepôt SQL sans serveur: arrêtez et redémarrez l’entrepôt SQL. Consultez Gérer un entrepôt SQL.
• Travaux Lakeflow : les modifications de stratégie réseau sont automatiquement appliquées lorsqu’une nouvelle exécution de travail est déclenchée ou qu’une exécution de travail existante est redémarrée.
• Notebooks :
  • Si votre bloc-notes n’interagit pas avec Spark, vous pouvez mettre fin au calcul serverless puis le rattacher à nouveau pour actualiser la stratégie réseau.
  • Si votre bloc-notes interagit avec Spark, votre ressource serverless est actualisée et détecte automatiquement la modification. La plupart des modifications seront actualisées en dix minutes, mais le basculement des modes d’accès à Internet, la mise à jour du mode d’exécution sèche ou la modification entre les stratégies jointes qui ont différents types d’application peuvent prendre jusqu’à 24 heures. Pour accélérer une actualisation sur ces types de modifications spécifiques, désactivez tous les blocs-notes et travaux associés.

Dépendances de l'interface utilisateur des Databricks Asset Bundles

Lorsque vous utilisez le mode d’accès restreint avec le contrôle de sortie Serverless, les fonctionnalités de l’interface utilisateur Databricks Asset Bundles nécessitent l’accès à des domaines externes spécifiques. Si l’accès sortant est complètement restreint, les utilisateurs peuvent rencontrer des erreurs dans l’interface de l’espace de travail lors de l’utilisation des bundles de ressources Databricks.

Pour conserver les fonctionnalités de l’interface utilisateur databricks Asset Bundles fonctionnant avec des stratégies réseau restreintes, ajoutez ces domaines aux domaines autorisés dans votre stratégie :

• github.com
• objects.githubusercontent.com
• release-assets.githubusercontent.com
• checkpoint-api.hashicorp.com
• releases.hashicorp.com
• registry.terraform.io

Vérifier l’application de la stratégie réseau

Vous pouvez vérifier que votre stratégie réseau est correctement appliquée en tentant d’accéder aux ressources restreintes à partir de différentes charges de travail serverless. Le processus de validation varie en fonction du produit serverless.

Valider avec les pipelines déclaratifs de Lakeflow Spark

1. Créez un notebook Python. Vous pouvez utiliser l’exemple de bloc-notes fourni dans le didacticiel wikipédia sur les pipelines déclaratifs Lakeflow Spark.
2. Créez un pipeline :
   1. Dans votre espace de travail, cliquez sur Travaux & Pipelines dans la barre latérale.
   2. Cliquez sur Créer, puis pipeline ETL.
   3. Configurez le pipeline avec les paramètres suivants :
      • Pipeline mode : Serverless
      • Code source : sélectionnez le bloc-notes que vous avez créé.
      • Options de stockage : Catalogue Unity. Sélectionnez votre catalogue et votre schéma souhaités.
   4. Cliquez sur Créer.
3. Exécuter le pipeline.
4. Dans la page du pipeline, cliquez sur Démarrer.
5. Attendez que le pipeline se termine.
6. Vérifier les résultats
   • Destination approuvée : le pipeline s’exécute correctement et écrit des données dans la destination.
   • Destination non approuvée : le pipeline échoue avec des erreurs, indiquant que l’accès réseau est bloqué.

Valider avec Databricks SQL

1. Créez un entrepôt SQL.

2. Exécutez une requête de test dans l’éditeur SQL qui tente d’accéder à une ressource contrôlée par votre stratégie réseau.

3. Vérifiez les résultats :

   • Destination approuvée : la requête réussit.
   • Destination non approuvée : la requête échoue avec une erreur d’accès réseau.

4. Pour vous connecter à un réseau à partir d’une fonction UDF à l’aide d’une bibliothèque Python standard, exécutez la définition UDF suivante :

   CREATE OR REPLACE TEMPORARY FUNCTION ping_google(value DOUBLE)
   RETURNS STRING
   LANGUAGE python
   AS $$
   import requests
   
   url = "https://www.google.com"
   response = requests.get(url, timeout=5)
   
   if response.status_code == 200:
      return "UDF has network!"
   else:
    return "UDF has no network!"
   $$;
   

Valider avec le service de modèle

Avant de commencer

Lorsqu’un point d'accès de service de modèle est créé, une image de conteneur est générée pour servir votre modèle. Les stratégies réseau sont appliquées pendant cette étape de construction. Lorsque vous utilisez un modèle servant avec des stratégies réseau, tenez compte des éléments suivants :

• Accès aux dépendances : Toutes les dépendances de build externes telles que les packages Python à partir de PyPI et conda-forge, les images conteneur de base ou les fichiers provenant d’URL externes spécifiées dans l’environnement de votre modèle ou le contexte Docker requis par l’environnement de votre modèle doivent être autorisés par votre stratégie réseau.

  • Par exemple, si votre modèle nécessite une version spécifique de scikit-learn qui doit être téléchargée pendant la génération, la stratégie réseau doit autoriser l’accès au référentiel hébergeant le package.

• Échecs de build : Si votre stratégie réseau bloque l’accès aux dépendances nécessaires, le modèle servant la build de conteneur échoue. Cela empêche le point de terminaison de service de se déployer avec succès et peut entraîner une incapacité à stocker ou à fonctionner correctement.

  Consultez Vérifier les journaux de déni.

• Résolution des problèmes de refus : Les refus d’accès réseau pendant la phase de génération sont enregistrés. Ces journaux d’activité comportent un champ network_source_type avec la valeur ML Build. Ces informations sont cruciales pour identifier les ressources spécifiques bloquées qui doivent être ajoutées à votre politique réseau pour permettre à la compilation de se terminer avec succès.

Valider l’accès réseau au runtime

Les étapes suivantes montrent comment valider la stratégie réseau pour un modèle déployé au moment de l’exécution, en particulier pour les tentatives d’accès aux ressources externes pendant l’inférence. Cela suppose que le conteneur de service de modèle a été créé avec succès, ce qui signifie que toutes les dépendances de temps de compilation ont été autorisées dans la stratégie réseau.

1. Créer un modèle de test

   1. Dans un notebook Python, créez un modèle qui tente d’accéder à une ressource Internet publique au moment de l’inférence, comme le téléchargement d’un fichier ou la création d’une requête d’API.

   2. Exécutez ce notebook pour générer un modèle dans l’espace de travail de test. Par exemple :

      import mlflow
      import mlflow.pyfunc
      import mlflow.sklearn
      import requests
      
      class DummyModel(mlflow.pyfunc.PythonModel):
          def load_context(self, context):
              # This method is called when the model is loaded by the serving environment.
              # No network access here in this example, but could be a place for it.
              pass
      
          def predict(self, _, model_input):
              # This method is called at inference time.
              first_row = model_input.iloc[0]
              try:
                  # Attempting network access during prediction
                  response = requests.get(first_row['host'])
              except requests.exceptions.RequestException as e:
                  # Return the error details as text
                  return f"Error: An error occurred - {e}"
              return [response.status_code]
      
      with mlflow.start_run(run_name='internet-access-model'):
          wrappedModel = DummyModel()
      
          # When this model is deployed to a serving endpoint,
          # the environment will be built. If this environment
          # itself (e.g., specified conda_env or python_env)
          # requires packages from the internet, the build-time SEG policy applies.
          mlflow.pyfunc.log_model(
              artifact_path="internet_access_ml_model",
              python_model=wrappedModel,
              registered_model_name="internet-http-access"
          )
      

2. Créer un point de service

   1. Dans la navigation de l’espace de travail, sélectionnez IA/ML.

   2. Cliquez sur l’onglet Service .

   3. Cliquez sur Créer un point de terminaison de service.

   4. Configurez le point de terminaison avec les paramètres suivants :

      • Nom du point de terminaison de service : indiquez un nom descriptif.
      • Détails de l’entité : sélectionnez Modèle de registre de modèles.
      • Modèle : choisissez le modèle que vous avez créé à l’étape précédente (internet-http-access).

   5. Cliquez sur Confirmer. À ce stade, le processus de construction du conteneur de service de modèle commence. Les stratégies réseau pour ML Build devront être appliquées. Si la build échoue en raison d’un accès réseau bloqué pour les dépendances, le point de terminaison ne sera pas prêt.

   6. Attendez que le point de terminaison de service atteigne l’état Prêt . S’il n’est pas prêt, vérifiez les journaux de déni pour les entrées network_source_type: ML Build.

      Consultez Vérifier les journaux de déni.

3. Interrogez le point de terminaison.

   1. Utilisez l’option Point de terminaison de requête dans la page de point de terminaison de service pour envoyer une demande de test.

      { "dataframe_records": [{ "host": "[https://www.google.com](https://www.google.com)" }] }
      

4. Vérifiez le résultat de l’accès au moment de l’exécution :

   • Accès Internet activé lors de l’exécution : la requête réussit et retourne un code d’état comme 200.
   • Accès Internet restreint au moment de l’exécution : la requête échoue avec une erreur d’accès réseau, telle que le message d’erreur du bloc dans le try-except code du modèle, indiquant un délai d’expiration de connexion ou un échec de résolution de l’hôte.

Mettre à jour une stratégie réseau

Vous pouvez mettre à jour une stratégie réseau à tout moment après sa création. Pour mettre à jour une stratégie réseau :

1. Dans la page d’informations de la stratégie réseau dans la console de vos comptes, modifiez la stratégie :
   • Modifiez le mode d’accès réseau.
   • Activez ou désactivez le mode d’exécution à sec pour des services spécifiques.
   • Ajoutez ou supprimez des noms de domaine complets ou des destinations de stockage.
2. Cliquez sur Update.
3. Reportez-vous à Appliquer des modifications de stratégie réseau pour vérifier que les mises à jour sont appliquées aux charges de travail existantes.

Vérifier les journaux de déni

Les journaux des refus sont stockés dans la table system.access.outbound_network d’Unity Catalog. Ces fichiers de journal suivent quand les demandes réseau sortantes sont refusées. Pour accéder aux journaux d’activité de refus, vérifiez que le schéma d’accès est activé dans votre metastore Unity Catalog. Consultez Activer les tables système.

Utilisez une requête SQL comme celle ci-dessous pour afficher les événements de déni. Si les journaux d’exécution sèche sont activés, la requête retourne à la fois les journaux de déni et les journaux d’activité à exécution sèche, que vous pouvez distinguer à l’aide de la colonne access_type. Les journaux de refus ont une valeur DROP, tandis que les journaux d’exécution sèche affichent DRY_RUN_DENIAL.

L'exemple suivant récupère les fichiers logs des 2 dernières heures :

SELECT *
FROM system.access.outbound_network
WHERE event_time >= CURRENT_TIMESTAMP() - INTERVAL 2 HOUR
ORDER BY event_time DESC;

Pour le mode test et les modèles d’IA générative externes, les éléments suivants sont vrais :

• Si votre stratégie réseau a bloqué l’accès aux dépendances nécessaires, vérifiez en premier lieu les journaux de déni dans system.access.outbound_network. En outre, les journaux de construction de votre conteneur de service de modèle peuvent fournir des informations utiles sur les domaines bloqués.
• Si la création du conteneur de service du modèle échoue, vérifiez les journaux de déni dans system.access.outbound_network pour déterminer quels domaines ont été bloqués.
• L’application de l’accès au modèle externe via Mosaic AI Serving continue même en mode test.

Limites

• Taille du chargement d’artefact : lors de l’utilisation du système de fichiers Databricks interne de MLflow avec le dbfs:/databricks/mlflow-tracking/<experiment_id>/<run_id>/artifacts/<artifactPath> format, les chargements d’artefacts sont limités à 5 Go pour log_artifact, log_artifactset log_model les API.
• Service de modèles : le contrôle de sortie ne s’applique pas lors de la création d’images pour le service de modèles.
• Remise des journaux de déni pour les charges de travail de garbage collection (GC) de courte durée : les journaux de déni des charges de travail de GC de courte durée de moins de 120 secondes peuvent ne pas être remis avant que le nœud ne termine en raison de retards de journalisation. Bien que l’accès soit toujours appliqué, l’entrée de journal correspondante peut être manquante.
• Connectivité réseau pour les fonctions définies par l’utilisateur Databricks SQL : pour activer l’accès réseau dans Databricks SQL, contactez votre équipe de compte Databricks.

• Journalisation des hooks d'événements de pipeline : Les pipelines déclaratifs Spark de Lakeflow qui ciblent un autre espace de travail ne sont pas journalisés. Cela s’applique aux eventhooks configurés pour les espaces de travail interrégions et les espaces de travail dans la même région.
• Modifications apportées aux liaisons de l’espace de travail dans Unity Catalog : les modifications apportées aux liaisons de l’espace de travail peuvent prendre jusqu’à 24 heures pour être effectives. Pour accélérer ce processus, ajoutez le compartiment de stockage à la stratégie réseau. Consultez Limiter l’accès au catalogue à des espaces de travail spécifiques.

• Accès réseau entre les clouds : les espaces de travail Azure utilisant des buckets S3 pour les emplacements externes du catalogue Unity ne sont pas actuellement autorisés par les stratégies réseau sans serveur.

Étapes suivantes

• Configurez le contrôle d’entrée basé sur le contexte : définissez des stratégies d’accès entrantes basées sur l’identité, le type de demande et la source réseau pour sécuriser l’accès à l’espace de travail. Consultez le contrôle d’entrée basé sur le contexte.
• Gérer les règles de point de terminaison privé : contrôlez le trafic réseau vers et à partir de vos points de terminaison privés en définissant des règles spécifiques qui autorisent ou refusent les connexions pour une sécurité renforcée. Consultez Gérer les règles de point de terminaison privé.
• Configurez un pare-feu pour l’accès au calcul serverless : implémentez un pare-feu pour restreindre et sécuriser les connexions réseau entrantes et sortantes pour vos environnements de calcul serverless. Voir Configurer un pare-feu pour l'accès à l'informatique sans serveur.
• Comprendre les coûts de transfert et de connectivité des données : découvrez les implications des coûts lors de l’implémentation des contrôles de sécurité réseau et de la connectivité privée pour les charges de travail serverless. Consultez Comprendre les coûts de mise en réseau sans serveur de Databricks.