Aller au contenu principal
Dernière mise à jour le

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

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

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

Exigences​

  • Votre Databricks Workspace doit être au niveau Entreprise.

  • Les autorisations de gestion des politiques réseau sont restreintes aux administrateurs de compte.

Accès aux politiques de réseau​

Pour créer, consulter et mettre à jour les politiques réseau dans votre compte :

  1. À partir de la console du compte, cliquez sur Sécurité .
  2. Cliquez sur l'onglet **tab**.
  3. Sous Stratégies , cliquez sur Contrôle d'entrée et de sortie basé sur le contexte .

Créer une politique de réseau​

  1. Cliquez sur Créer une nouvelle politique de réseau .

  2. Saisir un nom de politique .

  3. Cliquez sur l'onglet tab .

    Pour définir les règles d’entrée, consultez Définir les 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.

Détails de la politique réseau.

Configurer les stratégies réseau​

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

Définir les règles de sortie​

Veuillez noter avant de définir les règles de sortie :

  • Lorsque votre metastore et les compartiments S3 de votre emplacement externe UC sont situés dans des régions différentes, vous devez explicitement ajouter le compartiment à votre liste blanche de sortie pour que l’accès réussisse.

  • Le nombre maximal de destinations prises en charge est de 2 500.

  • Le nombre de destinations de stockage (allowed_storage_destinations) qui peuvent être ajoutées est limité à 100 par politique.

  • Le nombre de FQDNs pouvant être ajoutés en tant que domaines autorisés est limité à 100 par politique.

  • Les domaines ajoutés en tant qu'entrées Private Link pour un équilibreur de charge réseau sont implicitement ajoutés à la liste d'autorisation dans les politiques de réseau. Lorsqu'un domaine est supprimé ou que le Endpoint privé est effacé, l'application complète de la modification par les contrôles de stratégie réseau peut prendre jusqu'à 24 heures. Consultez Configurer la connectivité privée aux ressources dans votre Virtual Private Cloud (VPC).

  • Les compartiments OpenSharing sont explicitement autorisés dans les stratégies réseau.

remarque

L’autorisation implicite pour les connexions Unity Catalog est dépréciée. Pour les comptes contenant des Workspace qui utilisaient une liste verte implicite avant la dépréciation, ce comportement restera en vigueur pendant une période de transition limitée.

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

    Ajouter une destination Internet.

    Le filtre FQDN permet l'accès à tous les domaines qui partagent la même adresse IP.

remarque

Les Endpoint de throughput provisionné pour la diffusion de modèles ne prennent pas en charge le filtrage FQDN granulaire. Lorsque vous définissez l'accès réseau comme restreint, tout l'accès Internet est bloqué pour ces Endpoint.

  1. Pour permettre à votre workspace d'accéder à des buckets S3 supplémentaires, cliquez sur le bouton **Ajouter une destination** au-dessus de la liste **Destinations de stockage autorisées**.

    Ajouter une destination de stockage.

Seuls les emplacements de stockage externes liés à un Workspace, ou à tous les Workspaces, sont automatiquement inclus dans les politiques réseau. Pour vérifier qu'un emplacement est lié à votre Workspace, suivez ces étapes :

  1. Dans l’Explorateur de catalogues, ouvrez l’emplacement externe et vérifiez l’onglet Workspace pour confirmer que votre Workspace est attribué. Voir Assigner un emplacement externe à des Workspaces spécifiques.
  2. API/CLI : utilisez les liaisons de Workspace pour récupérer les liaisons pour l’emplacement externe :

Vous devez ajouter tous les FQDN valides pour accéder à des services supplémentaires.

remarque

L'accès direct aux services de stockage cloud depuis les conteneurs de code utilisateur, tels que les REPL ou les UDF, n'est pas autorisé par default. Pour activer cet accès, ajoutez le FQDN de la ressource de stockage sous Domaines autorisés dans votre politique. L'ajout uniquement du domaine de base de la ressource de stockage pourrait accorder par inadvertance l'accès à toutes les ressources de stockage de la région.

Application de la politique​

Le mode simulation vous permet de tester la configuration de votre politique et de surveiller les connexions sortantes sans perturber l'accès aux ressources. En mode simulation, les requêtes qui ne respectent pas la politique sont enregistrées, mais ne sont pas bloquées. Vous pouvez choisir parmi les options suivantes :

  1. Databricks SQL : Les warehouse Databricks SQL fonctionnent en mode d'essai.

  2. Déploiement de modèles IA : les Endpoint de déploiement de modèles fonctionnent en mode test.

  3. Tous les produits : tous les services Databricks fonctionnent en mode d'exécution à blanc, annulant toutes les autres sélections.

    Mode de simulation pour les politiques réseau.

Bloquer les destinations Internet​

remarque

Cette fonctionnalité est en version préliminaire publique et est disponible pour les Workspace éligibles SEG. Pour les Workspaces de niveau Entreprise qui ne sont pas encore éligibles SEG, les destinations bloquées ne sont prises en charge que dans la politique default lorsque l'accès réseau est défini sur un **accès complet**.

Bloquez les destinations Internet spécifiques de vos charges de travail serverless. Utilisez les destinations bloquées comme une alternative légère au mode Accès restreint pour bloquer les domaines malveillants connus sans changer le mode d'application général.

Configurez les destinations bloquées via l'API REST des politiques réseau. L'API nécessite un jeton OAuth d'administrateur de compte. Les jetons d'accès personnels ne sont pas pris en charge pour les APIs au niveau du compte.

Consultez l’article dédié à l’ authentification OAuth machine-à-machine.

Les destinations bloquées se comportent comme suit :

  • Chaque entrée spécifie un destination (un nom de domaine entièrement qualifié, ou FQDN) et un internet_destination_type de DNS_NAME.
  • Les plages d'adresses IP et les destinations de stockage ne sont pas prises en charge.
  • Les destinations bloquées sont toujours appliquées, quel que soit le mode d'accès réseau de la politique.
  • Les destinations bloquées priment sur les destinations autorisées.
  • L'API rejette les configurations où une destination autorisée est un sous-domaine d'une destination bloquée. Cependant, le modèle "autoriser largement, bloquer étroitement" est autorisé (par exemple, autoriser example.com et bloquer api.example.com).

Les refus sont enregistrés system.access.outbound_network dans la table de Unity Catalog, même lorsque l'accès réseau est défini sur **Full access**. Voir Consulter les logs de refus.

Pour bloquer une destination Internet :

  1. Récupérez votre politique réseau. Exécutez la commande suivante :

    Remplacez <ACCOUNT_HOST> par accounts.cloud.databricks.com.

    Bash
    curl --location --request GET \
      'https://<ACCOUNT_HOST>/api/2.0/accounts/<ACCOUNT_ID>/network-policies/<NETWORK_POLICY_ID>' \
      --header 'Authorization: Bearer <OAUTH_TOKEN>'

    Enregistrer le corps de la réponse sous le nom network-policy.json.

  2. Modifier network-policy.json pour ajouter blocked_internet_destinations sous egress.network_access. L'exemple suivant bloque un seul domaine en mode **Accès complet** :

    JSON
    {
      "network_policy_id": "my-policy",
      "account_id": "...",
      "egress": {
        "network_access": {
          "restriction_mode": "FULL_ACCESS",
          "blocked_internet_destinations": [
            {
              "destination": "malicious-domain.example.com",
              "internet_destination_type": "DNS_NAME"
            }
          ]
        }
      }
    }

  3. Soumettez la politique mise à jour avec une requête PUT vers le même Endpoint à l'aide de la commande suivante. Le corps PUT doit contenir la politique réseau complète. Tous les champs que vous omettez sont effacés.

    Bash
    curl --location --request PUT \
      'https://<ACCOUNT_HOST>/api/2.0/accounts/<ACCOUNT_ID>/network-policies/<NETWORK_POLICY_ID>' \
      --header 'Content-Type: application/json' \
      --header 'Authorization: Bearer <OAUTH_TOKEN>' \
      --data @network-policy.json

Vous pouvez également gérer les politiques réseau avec la CLI Databricks à l'aide de databricks account network-policies update-network-policy-rpc, ou avec la ressource Terraform databricks_account_network_policy. Consultez le groupe de commandesaccount network-policies.

Mettre à jour la politique default​

Chaque compte Databricks comprend une default policy . The default policy is associated with all Workspaces with no explicit network policy assignment, including newly created Workspaces. Vous pouvez modifier cette politique, mais elle ne peut pas être supprimée.

Les politiques default ne sont appliquées qu'aux Workspaces disposant au minimum du niveau Enterprise.

Associer une politique réseau aux Workspaces​

Si vous avez mis à jour votre politique default avec des configurations supplémentaires, elles sont automatiquement appliquées aux Workspaces qui n'ont pas de politique de réseau existante.

Votre Workspace doit être en niveau Entreprise.

Pour associer votre Workspace à une autre politique, veuillez procéder comme suit :

  1. Sélectionnez un {Workspace}.
  2. Dans Politique de réseau , cliquez sur Changer la politique applicable à l’espace de travail en matière de réseaux .
  3. Sélectionnez la politique réseau souhaitée dans la liste.
  4. Cliquez sur **Appliquer la politique**.

Mettre à jour la politique réseau.

Appliquer les modifications de la politique de réseau​

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

  • Ajout d'un nouvel emplacement externe ou d'une nouvelle connexion Unity Catalog.
  • Attacher votre workspace à un métastore différent.
  • Modification du stockage ou des destinations internet autorisés.
remarque

Vous devez redémarrer votre compute si vous modifiez l'accès à Internet ou le paramètre de mode de simulation.

Redémarrer ou redéployer les workloads serverless​

Vous n'avez besoin de mettre à jour que lorsque vous changez de mode d'accès à Internet ou lorsque vous mettez à jour le mode d'exécution à blanc.

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

  • Databricks ML Serving : Redéployez votre endpoint de service ML. Consultez Créer des endpoints de service de modèle personnalisés
  • Pipelines : Arrêtez puis redémarrez vos LakeFlow pipelines en cours d'exécution. Consultez Exécuter une mise à jour de pipeline.
  • Serverless SQL warehouse : Arrêter et redémarrer le SQL warehouse. Consultez Gérer un SQL Warehouse.
  • Lakeflow Jobs : les modifications de politique réseau sont automatiquement appliquées lorsqu'une nouvelle exécution de job est déclenchée ou qu'une exécution de job existante est redémarrée.
  • Notebook :
    • Si votre notebook n'interagit pas avec Spark, vous pouvez arrêter, puis rattacher le compute serverless pour refresh la politique réseau.
    • Si votre Notebook interagit avec Spark, votre Ressource Serverless refresh et détecte automatiquement le changement. La plupart des changements seront actualisés en dix minutes, mais le changement de modes d'accès internet, la mise à jour du mode simulation ou le passage entre des politiques attachées ayant des types d'application différents peut prendre jusqu'à 24 heures. Pour accélérer un refresh sur ces types de changements spécifiques, désactivez tous les notebooks et Jobs associés.

Dépendances de l’interface utilisateur des Declarative Automation Bundles​

Lorsque vous utilisez le mode d'accès restreint avec le contrôle de sortie serverless, les fonctionnalités d'interface utilisateur (UI) des Declarative Automation Bundles nécessitent l'accès à des domaines externes spécifiques. Si l'accès sortant est entièrement restreint, les utilisateurs pourraient voir des erreurs dans l'interface du workspace lorsqu'ils travaillent avec des Declarative Automation Bundles.

Pour que les fonctionnalités de l'interface utilisateur des Declarative Automation Bundles fonctionnent avec des politiques de réseau restreintes, ajoutez ces domaines aux Domaines autorisés de votre politique :

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

Vérifiez l'application de la politique réseau.​

Vous pouvez valider que votre politique réseau est correctement appliquée en tentant d'accéder à des ressources restreintes à partir de différentes charges de travail serverless. Le processus de validation varie selon le produit Serverless.

  1. Créez un Notebook Python. Vous pouvez utiliser le Notebook d'exemple fourni dans le tutoriel Python de LakeFlow Pipelines sur Wikipedia.

  2. Créer un pipeline :

    1. Dans votre Workspace, cliquez Icône Workflows. sur **Tâches et pipelines** dans la barre latérale.

    2. Cliquez sur **Créer**, puis sur **Pipeline ETL**.

    3. Configurez le pipeline avec les paramètres suivants :

      • Mode de pipeline : Serverless
      • Code source : Sélectionnez le Notebook que vous avez créé.
      • **Options de stockage** : Unity Catalog. Veuillez sélectionner le catalogue et le schéma souhaités.

    4. Cliquez sur Créer .

  3. Exécutez le pipeline.

  4. Dans la page du pipeline, cliquez sur Start .

  5. Veuillez attendre que le pipeline soit terminé.

  6. Vérifier les résultats

    • Destination approuvée : Le pipeline s'exécute avec succès et écrit les données dans la destination.
    • Destination non approuvée : le pipeline échoue avec des erreurs, indiquant que l’accès réseau est bloqué.

Mettre à jour une politique de réseau​

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

  1. Sur la page des détails de la politique réseau dans la console de vos comptes, modifiez la politique :

    • Modifier le mode d'accès au réseau.
    • Activez ou désactivez le mode de simulation pour des services spécifiques.
    • Ajouter ou supprimer des destinations FQDN ou de stockage.

  2. Cliquez sur Mettre à jour .

  3. Veuillez vous référer à Appliquer les modifications de la politique réseau pour vérifier que les mises à jour sont appliquées aux workloads existants.

Consulter les logs de refus​

Les logs de refus sont stockés dans la table system.access.outbound_network dans Unity Catalog. Ces logs suivent le moment où les requêtes réseau sortantes sont refusées. Pour accéder aux logs de refus, vérifiez que le schéma d'accès est activé sur votre métastore Unity Catalog. Consultez Activer les tables système.

Utilisez une query SQL comme celle ci-dessous pour afficher les événements de refus. Si les logs de simulation sont activés, la query renvoie à la fois les logs de refus et les logs de simulation, que vous pouvez distinguer à l’aide de la colonne access_type. Les logs de refus ont une valeur DROP , tandis que les logs de simulation affichent DRY_RUN_DENIAL .

L'exemple suivant récupère des Logs des 2 dernières heures :

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

Pour le mode de simulation et les modèles d'IA générative externes, ce qui suit est vrai :

  • Si votre politique réseau a bloqué l'accès aux dépendances nécessaires, vérifiez d'abord les journaux de refus dans system.access.outbound_network. De plus, les Logs de build de votre conteneur de service de modèle pourraient fournir des informations utiles sur les domaines qui ont été bloqués.
  • Si la création du conteneur de service de modèle échoue, vérifiez les journaux de refus dans system.access.outbound_network pour déterminer quels domaines ont été bloqués.
  • L’application de l’accès aux modèles externes via Model Serving se poursuit même en mode de test.
remarque

Il pourrait y avoir une latence perceptible entre le moment de l'accès et l'apparition des Logs de refus.

Limitations​

  • Taille de l'upload d'artefact : Lorsque vous utilisez le système de fichiers interne de Databricks de MLflow au dbfs:/databricks/mlflow-tracking/<experiment_id>/<run_id>/artifacts/<artifactPath> format, les uploads d'artefacts sont limités à 5 Go pour log_artifact log_artifacts log_model les API, et.

  • Livraison des logs de refus pour les charges de travail de collecte de déchets (GC) de courte durée : Les logs de refus des charges de travail GC de courte durée (moins de 120 secondes) pourraient ne pas être livrés avant la fin du nœud en raison de délais de journalisation. Bien que l'accès soit toujours appliqué, l'entrée de log correspondante peut être manquante.

  • Connectivité réseau pour les fonctions définies par l'utilisateur (UDF) Databricks SQL : pour activer l'accès réseau dans Databricks SQL, contactez votre équipe de compte Databricks.

  • **Journalisation des eventhooks de pipeline** : les eventhooks des Lakeflow pipelines qui ciblent un autre workspace ne sont pas journalisés. Cela s'applique aux Eventhooks configurés pour les workspaces interrégionaux et les workspaces de la même région.

  • Modifications des liaisons du workspace Unity Catalog : Les modifications des liaisons du workspace Unity Catalog peuvent prendre jusqu'à 24 heures pour prendre effet. Pour accélérer ce processus, ajoutez le compartiment de stockage à la politique de réseau. Voir liaison Workspace-catalogue.

  • Accès réseau aux emplacements S3 du Unity Catalog inter-régions : les compartiments S3 utilisés pour les emplacements externes du Unity Catalog qui se trouvent dans une région AWS différente du metastore ne sont pas automatiquement autorisés par les politiques réseau serverless. Ces emplacements S3 inter-régions doivent être explicitement ajoutés aux destinations autorisées de votre politique réseau pour permettre l’accès depuis des charges de travail serverless.

Étapes suivantes​

  • **Configurer le contrôle d'entrée basé sur le contexte :** Définissez des stratégies d'accès entrant basées sur l'identité, le type de requête et la source réseau pour sécuriser l'accès au Workspace. Consultez le contrôle d'entrée basé sur le contexte.
  • Gérer les règles d'endpoint privé : Contrôlez le trafic réseau vers et depuis vos endpoints 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 d'endpoint privé.
  • Configurer un pare-feu pour l'accès au compute serverless : Implémentez un pare-feu pour restreindre et sécuriser les connexions réseau entrantes et sortantes pour vos environnements de compute serverless. Voir la configuration du pare-feu pour le compute serverless.
  • Comprendre les coûts de transfert de données et de connectivité : Découvrez les implications en termes de coûts lors de la mise en œuvre de contrôles de sécurité réseau et de connectivité privée pour les charges de travail serverless. Consulter Comprendre les coûts réseau de Databricks.
Sur cette page