Gestion des stratégies réseau pour le contrôle de sortie serverless

Article
02/07/2025

Important

Cette fonctionnalité est disponible en préversion publique.

Ce document 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.

Les autorisations de gestion des stratégies réseau sont limitées à l’administrateur de compte. Consultez l’introduction de l’administration Azure Databricks.

Accès aux politiques réseau

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

Dans la console de compte, cliquez sur Ressources cloud.
Cliquez sur l’onglet Réseau .

liste de stratégies réseau.

Créer une stratégie réseau

Cliquez sur Créer une stratégie réseau.
Choisissez un mode d’accès réseau :
- accès complet: accès Internet sortant illimité. Si vous choisissez Accès complet, l’accès Internet sortant reste illimité.
- accès restreint: l’accès sortant est limité aux destinations spécifiées. Pour plus d’informations, consultez vue d’ensemble de la stratégie réseau.

Configurer des stratégies réseau

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

Règles de sortie

Les destinations configurées par le biais d’emplacements de catalogue Unity ou de connexions sont automatiquement autorisées par la stratégie.

Pour accorder à votre calcul serverless l’accès à des domaines supplémentaires, cliquez sur Ajouter 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 lorsque l’accès réseau est limité. Toutefois, le contrôle granulaire avec le filtrage FQDN n’est pas pris en charge.
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 comptes de stockage autorisés.

Remarque

Le nombre maximal de destinations prises en charge est de 2000. Cela inclut tous les emplacements et connexions du catalogue Unity accessibles à partir de l’espace de travail, ainsi que les destinations explicitement ajoutées dans la politique.

Application de stratégies

Le mode journal uniquement 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 :

Databricks SQL: les entrepôts Databricks SQL fonctionnent en mode de fonctionnement sec.
Modèle IA servant : les points de terminaison de service de modèle fonctionnent en mode d’exécution sèche.
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 :

Sélectionnez un espace de travail.
Dans Politique de réseau, cliquez sur Mettre à jour la politique de réseau.
Sélectionnez la stratégie réseau souhaitée dans la liste.

mettre à jour la stratégie réseau.

Appliquer des modifications de stratégie réseau

La plupart des mises à jour de configuration réseau se propagent automatiquement à votre calcul serverless dans les 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.

Remarque

Vous devez redémarrer votre calcul si vous modifiez le paramètre d’accès Internet ou de mode de fonctionnement sec.

Redémarrer ou redéployer des charges de travail serverless

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
Delta Live Tables : arrêtez, puis redémarrez votre pipeline Delta Live Tables en cours d’exécution. Consultez Exécuter une mise à jour sur un pipeline Delta Live Tables.
l’entrepôt SQL sans serveur: arrêtez et redémarrez l’entrepôt SQL. Consultez Gérer un entrepôt SQL.
Flux de travail : 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.
Blocs-notes :
- Si votre bloc-notes n’interagit pas avec Spark, vous pouvez arrêter et attacher un nouveau cluster serverless pour actualiser votre configuration réseau appliquée à votre bloc-notes.
- Si votre bloc-notes interagit avec Spark, votre ressource serverless est actualisée et détecte automatiquement la modification. Le basculement du mode d’accès et du mode exécution sèche peut prendre jusqu’à 24 heures, et d’autres modifications peuvent prendre jusqu’à 10 minutes pour s’appliquer.

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 tables dynamiques Delta

Créez un notebook Python. Vous pouvez utiliser l’exemple de bloc-notes fourni dans le didacticiel wikipédia sur les tables dynamiques Delta.
Créez un pipeline Delta Live Tables :
1. Cliquez sur Pipelines, sous Ingénierie des données, dans la barre latérale de l’espace de travail.
2. Cliquez sur Créer un pipeline.
3. Configurez le pipeline avec les paramètres suivants :
  - Mode pipeline : 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.
Exécutez le pipeline Delta Live Tables.
Dans la page du pipeline, cliquez sur Démarrer.
Attendez que le pipeline se termine.
Vérifier les résultats
- Destination approuvée : le pipeline doit s’exécuter correctement et écrire des données dans la destination.
- Destination non approuvée : le pipeline doit échouer avec des erreurs indiquant que l’accès réseau est bloqué.

Valider avec Databricks SQL

Créez un SQL Warehouse. Pour obtenir des instructions, consultez Créer un entrepôt SQL.
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.
Vérifiez les résultats :
- Destination approuvée : la requête doit réussir.
- Destination non approuvée : la requête doit échouer avec une erreur d’accès réseau.

Valider avec le service de modèle

Créer un modèle de test

Dans un notebook Python, créez un modèle qui tente d’accéder à une ressource Internet publique, comme télécharger un fichier ou effectuer une demande d’API.
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):
        pass

    def predict(self, _, model_input):
        first_row = model_input.iloc[0]
        try:
            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()

    mlflow.pyfunc.log_model(artifact_path="internet_access_ml_model", python_model=wrappedModel, registered_model_name="internet-http-access")

Créer un point de terminaison de service
1. Dans la navigation de l’espace de travail, sélectionnez Machine Learning.
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.
5. Cliquez sur Confirmer.
6. Attendez que le point de terminaison de service atteigne l’état Prêt .
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"}]}
```
Vérifiez le résultat :
- Accès Internet activé : la requête doit réussir.
- Accès Internet restreint : la requête doit échouer avec une erreur d’accès réseau.

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 :

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.
Cliquez sur Update.
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 d’activité de déni

Les journaux de refus sont stockés dans la table dans le system.access.outbound_network catalogue Unity. Ces journaux effectuent le suivi lorsque les demandes réseau sortantes sont refusées. Pour accéder aux journaux de refus, vérifiez que le schéma d’accès est activé sur votre metastore du catalogue Unity. Consultez Activer les schémas de table 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 journaux des 2 dernières heures :


select * from system.access.outbound_network
where event_time >= current_timestamp() - interval 2 hour
sort by event_time desc

Les dénis ne sont pas enregistrés dans la table système de sortie du réseau lors de la connexion à des modèles d'IA générative externes avec le Mosaic AI Gateway. Consultez Mosaic AI Gateway.