Aller au contenu principal
Dernière mise à jour le

Configurez un VPC géré par le client

Cette page décrit les avantages et l'implémentation d'un Virtual Private Cloud (VPC) géré par le client.

Présentation​

Par défaut, les clusters Databricks sont créés dans un seul VPC (cloud privé virtuel) AWS que Databricks crée et configure dans votre compte AWS.

Vous pouvez également créer vos workspaces Databricks au sein de votre propre Virtual Private Cloud (VPC). Cette fonctionnalité est connue sous le nom de Virtual Private Cloud (VPC) géré par le client .

important

Changement à venir

Dans une future version, Databricks prévoit de déprécier la création classique de Workspace avec un Virtual Private Cloud (VPC) géré par Databricks. Les nouveaux Workspaces classiques nécessiteront un Virtual Private Cloud (VPC) géré par le client. Pour un start rapide plus simple, utilisez un Workspace Serverless. Pour plus de détails, consultez Un Virtual Private Cloud (VPC) géré par le client sera bientôt requis pour les Workspace classiques.

Utilisez un Virtual Private Cloud (VPC) géré par le client pour :

  • Contrôle amélioré : Exercez un contrôle accru sur vos configurations réseau.
  • Conformité : Respectez les normes de sécurité cloud et de gouvernance spécifiques requises par votre organisation.
  • Politiques internes : Respecter les politiques de sécurité qui empêchent les fournisseurs de créer des VPC dans votre compte AWS.
  • Processus d'approbation clairs : alignez-vous sur les processus d'approbation internes où les VPC doivent être configurés et sécurisés par vos propres équipes (par exemple, sécurité des informations, cloud engineering).
  • AWS PrivateLink : Un Virtual Private Cloud (VPC) géré par le client est requis pour le plan de compute classique (back-end) et AWS PrivateLink entrant (front-end) sur les workspaces avec un plan de compute classique. Les workspaces Serverless uniquement et AWS PrivateLink sortant (plan de compute Serverless) ne nécessitent pas de Virtual Private Cloud (VPC) géré par le client.

Avantages inclus :

  • Niveau de privilège inférieur : Maintenez plus de contrôle sur votre compte AWS. Databricks requiert moins d'autorisations en utilisant son rôle IAM inter-comptes par rapport à la configuration par default, ce qui peut simplifier les approbations internes.

  • Opérations réseau simplifiées : obtenez une meilleure utilisation de l'espace réseau en configurant des sous-réseaux plus petits pour un Workspace par rapport au CIDR /16 default. Évitez les configurations d'appairage Virtual Private Cloud (VPC) potentiellement complexes.

  • **Virtual Private Cloud (VPC) consolidés :** Plusieurs workspaces Databricks peuvent partager un seul VPC de plan de compute classique, ce qui est souvent préférable pour la facturation et la gestion des instances.

  • Limiter les connexions sortantes : utilisez un pare-feu de sortie ou une appliance proxy pour limiter le trafic sortant à une liste de sources de données internes ou externes autorisées.

Virtual Private Cloud (VPC) géré par le client

Pour tirer parti d'un Virtual Private Cloud (VPC) géré par le client, vous devez spécifier un Virtual Private Cloud (VPC) lors de la première création du workspace Databricks. Vous ne pouvez pas déplacer un workspace existant avec un Virtual Private Cloud (VPC) géré par Databricks pour utiliser un VPC géré par le client. Vous pouvez, cependant, déplacer un workspace existant avec un Virtual Private Cloud (VPC) géré par le client d'un VPC vers un autre VPC en mettant à jour l'objet de configuration réseau de la configuration du workspace. Consultez Mettre à jour un workspace en cours d'exécution ou en échec.

Pour déployer un workspace dans votre propre VPC, vous devez :

  1. Créez le Virtual Private Cloud (VPC) en suivant les exigences énumérées dans Exigences du Virtual Private Cloud (VPC).

  2. Référencez votre configuration réseau de Virtual Private Cloud (VPC) avec Databricks lorsque vous créez le Workspace.

    Vous devez fournir l'ID du Virtual Private Cloud (VPC), les ID des sous-réseaux et l'ID du groupe de sécurité lorsque vous enregistrez le VPC auprès de Databricks.

Exigences du Virtual Private Cloud (VPC)​

Votre Virtual Private Cloud (VPC) doit satisfaire aux exigences décrites dans cette section pour héberger un workspace Databricks.

Exigences :

Région Virtual Private Cloud (VPC)​

Pour obtenir la liste des régions AWS qui prennent en charge le Virtual Private Cloud (VPC) géré par le client, consultez les fonctionnalités avec disponibilité régionale limitée.

Dimensionnement du Virtual Private Cloud (VPC)​

Vous pouvez partager un Virtual Private Cloud (VPC) avec plusieurs Workspaces dans un seul compte AWS. Toutefois, Databricks recommande d'utiliser des sous-réseaux et des groupes de sécurité uniques pour chaque Workspace. Veillez à dimensionner votre Virtual Private Cloud (VPC) et vos sous-réseaux en conséquence. Databricks attribue deux adresses IP par nœud, une pour le trafic de gestion et une pour les applications Apache Spark. Le nombre total d'instances pour chaque sous-réseau est égal à la moitié du nombre d'adresses IP disponibles. En savoir plus dans Sous-réseaux.

Plages d'adresses IP du Virtual Private Cloud (VPC)​

Databricks ne limite pas les masques de réseau pour le Virtual Private Cloud (VPC) du Workspace, mais chaque sous-réseau de Workspace doit avoir un masque de réseau entre /17 et /26. Cela signifie que si votre Workspace dispose de deux sous-réseaux et que les deux ont un masque de sous-réseau de /26, alors le masque de sous-réseau de votre Virtual Private Cloud (VPC) Workspace doit être de /25 ou moins.

important

Si vous avez configuré des blocs CIDR secondaires pour votre Virtual Private Cloud (VPC), assurez-vous que les sous-réseaux pour le Databricks Workspace sont configurés avec le même bloc CIDR de Virtual Private Cloud (VPC).

DNS​

Le Virtual Private Cloud (VPC) doit avoir les noms d'Hostname DNS et la résolution DNS activés.

Sous-réseaux​

Databricks doit avoir accès à au moins deux sous-réseaux pour chaque workspace , chaque sous-réseau se trouvant dans une zone de disponibilité différente. Vous ne pouvez pas spécifier plus d'un sous-réseau Databricks Workspace par zone de disponibilité dans l'appel API de création de configuration réseau. Vous pouvez avoir plus d'un sous-réseau par zone de disponibilité dans le cadre de votre configuration réseau, mais vous ne pouvez choisir qu'un seul sous-réseau par zone de disponibilité pour le Workspace Databricks.

Vous pouvez choisir de partager un sous-réseau avec plusieurs Workspaces ou les deux sous-réseaux avec plusieurs Workspaces. Par exemple, vous pouvez avoir deux Workspace qui partagent le même Virtual Private Cloud (VPC). Un Workspace peut utiliser les sous-réseaux A et B et un autre Workspace peut utiliser les sous-réseaux A et C. Si vous prévoyez de partager des sous-réseaux avec plusieurs Workspace, assurez-vous de dimensionner votre Virtual Private Cloud (VPC) et vos sous-réseaux pour qu'ils soient suffisamment grands pour monter en charge avec l'utilisation.

Databricks attribue deux adresses IP par nœud, une pour le trafic de gestion et une pour les applications Spark. Le nombre total d’instances pour chaque sous-réseau est égal à la moitié du nombre d’adresses IP disponibles.

Chaque sous-réseau doit avoir un masque de sous-réseau compris entre /17 et /26.

Exigences supplémentaires en matière de sous-réseau​

  • Les sous-réseaux doivent être privés.
  • Les sous-réseaux doivent avoir un accès sortant au réseau public à l'aide d'une passerelle NAT et d'une passerelle Internet, ou d'une autre infrastructure d'appliances similaire gérée par le client.
  • La passerelle NAT doit être configurée dans son propre sous-réseau qui achemine le trafic quad-zéro (0.0.0.0/0) vers une passerelle internet ou une autre infrastructure d'appliance gérée par le client.
important

Les Workspaces doivent avoir un accès sortant depuis le VPC vers le réseau public. Si vous configurez des listes d'accès IP, ces réseaux publics doivent être ajoutés à une liste d'autorisation. Voir Configurer les listes d’accès IP pour les Workspace.

Table de routage du sous-réseau​

La table de routage des sous-réseaux du Workspace doit avoir un trafic quad-zéro (0.0.0.0/0) qui cible le périphérique réseau approprié. Le trafic quad-zéro doit cibler une passerelle NAT ou votre propre appareil NAT géré ou appliance proxy.

important

Databricks exige des sous-réseaux pour ajouter 0.0.0.0/0 à votre liste d'autorisation. Ceci doit être la première règle priorisée. Pour contrôler le trafic de sortie, utilisez un pare-feu de sortie ou un dispositif de proxy pour bloquer la plupart du trafic, mais autorisez les URL auxquelles Databricks doit se connecter. Consultez Configurer un pare-feu et l'accès sortant.

Il s'agit uniquement d'une ligne directrice de base. Vos exigences de configuration peuvent varier. Pour toute question, contactez l’équipe de votre compte Databricks.

Groupes de sécurité​

Un Databricks Workspace doit avoir accès à au moins un groupe de sécurité AWS et à cinq groupes de sécurité au maximum. Vous pouvez réutiliser des groupes de sécurité existants plutôt que d'en créer de nouveaux. Cependant, Databricks recommande d'utiliser des sous-réseaux et des groupes de sécurité uniques pour chaque Workspace.

Les groupes de sécurité doivent comporter les règles suivantes :

Sortie (sortant) :

  • Autoriser tous les accès TCP et UDP au groupe de sécurité du workspace (pour le trafic interne)
  • Autoriser l'accès TCP à 0.0.0.0/0 pour ces ports :
    • 443 : pour l'infrastructure Databricks, les sources de données cloud et les repositories de bibliothèques
    • 3306 : pour le Hive metastore hérité
    • 53 : pour la résolution DNS lorsque vous utilisez un DNS personnalisé.
    • 6666 : pour une connectivité sécurisée des clusters. Cela n'est requis que si vous utilisez PrivateLink.
    • 2443 : Prend en charge le chiffrement FIPS. Obligatoire uniquement si vous activez le profil de sécurité de la conformité.
    • 5432 : pour les connexions du plan de compute classique à Lakebase.
    • 8443, 8445 : pour les appels internes du plan de compute Databricks vers l'API du plan de contrôle Databricks.
    • 8444 : pour la journalisation du Unity Catalog et le streaming des données de lignage dans Databricks.
    • De 8446 à 8451 : réservé pour une utilisation future.

Ingress (entrée) : requis pour tous les workspaces (ces règles peuvent être séparées ou combinées) :

  • Autoriser le TCP sur tous les ports lorsque la source de trafic utilise le même groupe de sécurité
  • Autoriser l'UDP sur tous les ports lorsque la source de trafic utilise le même groupe de sécurité.

ACL réseau au niveau du sous-réseau​

Les ACL réseau au niveau du sous-réseau ne doivent pas refuser l'entrée ou la sortie à aucun trafic. Databricks valide les règles suivantes lors de la création du workspace :

Sortie (sortant) :

  • Autoriser tout le trafic vers le CIDR du Virtual Private Cloud (VPC) du workspace, pour le trafic interne
    • Autoriser l'accès TCP à 0.0.0.0/0 pour ces ports :
      • 443 : pour l'infrastructure Databricks, les sources de données cloud et les repositories de bibliothèques
      • 3306 : pour le Hive metastore hérité
      • 6666 : requis uniquement si vous utilisez PrivateLink
      • 8443, 8445 : pour les appels internes du plan de compute Databricks vers l'API du plan de contrôle Databricks
      • 8444 : pour la journalisation Unity Catalog et le streaming de données de lignage dans Databricks
important

Si vous configurez des règles ALLOW ou DENY supplémentaires pour le trafic sortant, définissez les règles requises par Databricks à la priorité la plus élevée (les numéros de règles les plus bas), afin qu'elles aient la préséance.

Entrée (entrant) :

  • ALLOW ALL from Source 0.0.0.0/0. Cette règle doit être priorisée.
remarque

Databricks exige des listes de contrôle d'accès réseau au niveau du sous-réseau pour ajouter 0.0.0.0/0 à votre liste d'autorisation. Pour contrôler le trafic sortant, utilisez un pare-feu sortant ou un appareil proxy pour bloquer la majeure partie du trafic, mais autorisez les URL auxquelles Databricks doit se connecter. Consultez Configurer un pare-feu et l'accès sortant.

Si vous prévoyez d'activer AWS PrivateLink sur le workspace avec ce Virtual Private Cloud (VPC) :

  • Sur le Virtual Private Cloud (VPC), assurez-vous d’activer les deux paramètres Noms d’hôte DNS et Résolution DNS.
  • Consultez l'article Configurer la connectivité privée classique à Databricks pour obtenir des indications sur la création d'un sous-réseau supplémentaire pour les endpoints Virtual Private Cloud (VPC) (recommandé mais non obligatoire) et la création d'un groupe de sécurité supplémentaire pour les endpoints Virtual Private Cloud (VPC).

Créez un VPC​

Pour créer des VPC, vous pouvez utiliser différents outils :

Pour utiliser la console AWS, les instructions de base pour la création et la configuration d'un Virtual Private Cloud (VPC) et des objets associés sont énumérées ci-dessous. Pour des instructions complètes, consultez la documentation AWS.

remarque

Ces instructions de base peuvent ne pas s'appliquer à toutes les organisations. Vos exigences de configuration peuvent varier. Cette section ne couvre pas toutes les manières possibles de configurer les NAT, les pare-feu ou d'autres infrastructures réseau. Si vous avez des questions, veuillez contacter l'équipe de votre compte Databricks avant de continuer.

  1. Veuillez consulter la page Virtual Private Cloud (VPC) dans AWS.

  2. Consultez le sélecteur de région en haut à droite. Si nécessaire, basculez vers la région de votre Workspace.

  3. Dans le coin supérieur droit, veuillez cliquer sur le bouton orange **Créer un Virtual Private Cloud (VPC)**.

    créer un nouvel éditeur Virtual Private Cloud (VPC)

  4. Cliquez sur Virtual Private Cloud (VPC) et plus .

  5. Dans la génération automatique des tags de nom , saisissez un nom pour votre workspace. Databricks recommande d'inclure la région dans le nom.

  6. Pour la plage d'adresses Virtual Private Cloud (VPC), modifiez-la si vous le souhaitez.

  7. Pour les sous-réseaux publics, cliquez sur 2. Ces sous-réseaux ne sont pas utilisés directement par votre Workspace Databricks, mais ils sont nécessaires pour activer les NATs dans cet éditeur.

  8. Pour les sous-réseaux privés, cliquez sur 2 pour le minimum pour les sous-réseaux du workspace. Vous pouvez en ajouter plus si vous le souhaitez.

    Votre workspace Databricks nécessite au moins deux sous-réseaux privés. Pour les redimensionner, cliquez sur Personnaliser les blocs CIDR du sous-réseau .

  9. Pour les passerelles NAT, cliquez sur Dans 1 AZ .

  10. Assurez-vous que les champs suivants en bas sont activés : Activer les noms d'hôte DNS et Activer la résolution DNS .

  11. Cliquez sur Créer un Virtual Private Cloud (VPC) .

  12. Lors de l'affichage de votre nouveau Virtual Private Cloud (VPC), cliquez sur les éléments de navigation de gauche pour mettre à jour les paramètres associés sur le Virtual Private Cloud (VPC). Pour faciliter la recherche d'objets associés, dans le champ Filtrer par Virtual Private Cloud (VPC) , sélectionnez votre nouveau Virtual Private Cloud (VPC).

  13. Cliquez sur Sous-réseaux et sur ce qu’AWS appelle les sous-réseaux privés numérotés 1 et 2, que vous utiliserez pour configurer les sous-réseaux principaux de votre workspace. Modifiez les sous-réseaux comme indiqué dans les exigences de Virtual Private Cloud (VPC).

    Si vous avez créé un sous-réseau privé supplémentaire à utiliser avec PrivateLink, configurez le sous-réseau privé 3 tel que spécifié dans Configurez la connectivité privée classique à Databricks.

  14. Cliquez sur **Groupes de sécurité** et modifiez le groupe de sécurité comme spécifié dans Groupes de sécurité.

    Si vous utilisez la connectivité PrivateLink back-end, créez un groupe de sécurité supplémentaire avec des règles entrantes et sortantes, comme spécifié dans l'article PrivateLink, dans la section Configurer les objets réseau AWS.

  15. Cliquez sur ACL réseau et modifiez les ACL réseau comme spécifié dans Listes de contrôle d'accès réseau au niveau du sous-réseau.

  16. Choisissez d'effectuer ou non les configurations optionnelles spécifiées plus loin dans cet article.

Enregistrez votre Virtual Private Cloud (VPC) avec Databricks​

Après avoir créé votre VPC et configuré les objets réseau requis, vous devez faire référence à ce VPC, y compris à des objets réseau tels que des VPC, des sous-réseaux et des groupes de sécurité, dans une configuration réseau pour votre compte Databricks. Vous pouvez créer la configuration réseau à l'aide de la console du compte ou en utilisant l'API du compte.

important

Si vous prévoyez de partager un Virtual Private Cloud (VPC) et des sous-réseaux sur plusieurs Workspace, assurez-vous de dimensionner votre VPC et vos sous-réseaux pour qu'ils soient suffisamment grands pour s'adapter à l'utilisation. Vous ne pouvez pas réutiliser un objet de configuration réseau sur plusieurs workspaces.

  1. Dans la console du compte, cliquez sur Sécurité .

  2. Dans la section Configurations réseau classiques , cliquez sur Ajouter une configuration réseau .

  3. Dans le champ Nom de la configuration réseau , saisissez un nom lisible par un humain pour votre nouvelle configuration réseau.

  4. Dans le champ ID du Virtual Private Cloud (VPC) , saisissez l'ID du Virtual Private Cloud (VPC).

  5. Dans le champ ID de sous-réseau , saisissez les ID d'au moins deux sous-réseaux AWS dans le Virtual Private Cloud (VPC). Pour les exigences de configuration réseau, consultez les exigences relatives au Virtual Private Cloud (VPC).

  6. Dans le champ ID du groupe de sécurité , saisissez l'ID d'au moins un groupe de sécurité AWS. Pour connaître les exigences de configuration réseau, veuillez consulter les groupes de sécurité.

  7. (Facultatif) Pour prendre en charge la connectivité back-end AWS PrivateLink, vous devez sélectionner deux enregistrements d'endpoints Virtual Private Cloud (VPC) à partir des champs sous l'en-tête Connectivité privée back-end .

    Connectivité privée back-end

    1. Si vous n'avez pas encore créé les deux endpoints AWS VPC spécifiques à la région de votre workspace, vous devez le faire maintenant. Consultez Créer des Endpoint Virtual Private Cloud (VPC). Vous pouvez utiliser la console AWS ou divers outils d'automatisation.
    2. Pour chaque champ, choisissez des enregistrements d'endpoint VPC existants, ou choisissez Enregistrer un nouvel endpoint VPC pour en créer un immédiatement qui fait référence aux endpoints VPC AWS que vous avez déjà créés. Pour obtenir des conseils sur les champs, consultez Gérer les enregistrements d’Endpoint Virtual Private Cloud (VPC).

  8. Cliquez sur **Ajouter**.

Configuration réseau

Mise à jour des CIDR​

Vous devrez peut-être, ultérieurement, mettre à jour les CIDR de sous-réseau qui chevauchent les sous-réseaux d'origine.

Pour mettre à jour les CIDR et d'autres objets du workspace :

  1. Arrêtez tous les clusters en cours d’exécution (et autres ressources de compute) qui sont en cours d’exécution dans les sous-réseaux qui doivent être mis à jour.

  2. À l'aide de la console AWS, supprimez les sous-réseaux à mettre à jour.

  3. Recréer les sous-réseaux avec les plages CIDR mises à jour.

  4. Mettez à jour l'association de la table de routage pour les deux nouveaux sous-réseaux. Vous pouvez réutiliser ceux de chaque zone de disponibilité pour les sous-réseaux existants.

important

Si vous ignorez cette étape ou configurez incorrectement les tables de routage, le cluster pourrait ne pas parvenir à se lancer.

  1. Créez un nouvel objet de configuration réseau avec les nouveaux sous-réseaux.

  2. Mettez à jour le Workspace pour utiliser cet objet de configuration réseau nouvellement créé.

(Recommandé) Configurez les endpoints régionaux​

Si vous utilisez un Virtual Private Cloud (VPC) géré par le client (facultatif), Databricks vous recommande de configurer votre Virtual Private Cloud (VPC) pour utiliser uniquement des Endpoints Virtual Private Cloud (VPC) régionaux vers les services AWS. L'utilisation d'Endpoint VPC régionaux permet des connexions plus directes aux services AWS et un coût réduit par rapport aux Endpoint mondiaux AWS. Quatre services AWS qu'un Workspace Databricks doté d'un Virtual Private Cloud (VPC) géré par le client doit atteindre : STS, S3, Kinesis et RDS.

La connexion de votre Virtual Private Cloud (VPC) au service RDS est requise uniquement si vous utilisez le Hive metastore hérité Databricks par default et ne s'applique pas aux métastores Unity Catalog. Bien qu'il n'y ait pas de Endpoint Virtual Private Cloud (VPC) pour RDS, au lieu d'utiliser le Hive metastore hérité Databricks par défaut, vous pouvez configurer votre propre metastore externe. Vous pouvez implémenter un metastore externe avec un Hive metastore ou AWS Glue.

Pour les trois autres services, vous pouvez créer des Endpoint de passerelle ou d'interface Virtual Private Cloud (VPC) afin que le trafic pertinent dans la région des clusters puisse transiter par le backbone sécurisé AWS plutôt que par le réseau public :

  • S3 : Créez un endpoint de passerelle Virtual Private Cloud (VPC) directement accessible depuis les sous-réseaux de votre cluster Databricks. Cela entraîne que le trafic du workspace vers tous les compartiments S3 intra-régionaux utilise l'itinéraire de l'endpoint. Pour accéder à des compartiments interrégionaux, ouvrez l'accès à l'URL globale S3 s3.amazonaws.com dans votre dispositif de sortie, ou acheminez 0.0.0.0/0 vers une passerelle Internet AWS.

    Pour utiliser les montages DBFS avec les Endpoints régionaux activés :

    • Vous devez configurer une variable d’environnement dans la configuration du cluster pour définir AWS_REGION=<aws-region-code>. Par exemple, si votre workspace est déployé dans la région N. Virginia, définissez AWS_REGION=us-east-1. Pour l’appliquer à tous les clusters, utilisez les politiques de cluster.

  • STS : Créez un point de terminaison d'interface Virtual Private Cloud (VPC) directement accessible à partir des sous-réseaux de vos clusters Databricks. Vous pouvez créer ce Endpoint dans les sous-réseaux de votre Workspace. Databricks vous recommande d'utiliser le même groupe de sécurité que celui qui a été créé pour le Virtual Private Cloud (VPC) de votre Workspace. Cette configuration amène le trafic du Workspace vers STS à utiliser la route de l'Endpoint.

  • Kinesis : créez un Endpoint d'interface Virtual Private Cloud (VPC) directement accessible depuis les sous-réseaux de votre Databricks clusters. Vous pouvez créer ce Endpoint dans les sous-réseaux de votre Workspace. Databricks vous recommande d'utiliser le même groupe de sécurité que celui qui a été créé pour le Virtual Private Cloud (VPC) de votre Workspace. Cette configuration fait en sorte que le trafic du workspace vers Kinesis utilise l’itinéraire du endpoint. La seule exception à cette règle concerne les Workspace de la région AWS us-west-1, car les Stream Kinesis cibles de cette région sont interrégionaux par rapport à la région us-west-2.

Configurez un pare-feu et un accès sortant​

Vous devez utiliser un pare-feu de sortie ou une appliance proxy pour bloquer la plupart du trafic, mais autoriser les URL auxquelles Databricks doit se connecter :

  • Si le pare-feu ou l'appliance proxy se trouve dans le même Virtual Private Cloud (VPC) que le Virtual Private Cloud (VPC) du Databricks Workspace, routez le trafic et configurez-le pour autoriser les connexions suivantes.
  • Si le pare-feu ou l'appliance proxy se trouve dans un Virtual Private Cloud (VPC) ou un réseau on-premise différent, acheminez 0.0.0.0/0 vers ce Virtual Private Cloud (VPC) ou ce réseau en premier et configurez l'appliance proxy pour autoriser les connexions suivantes.
important

Databricks vous recommande vivement de spécifier les destinations en tant que noms de domaine dans votre infrastructure de sortie, plutôt qu'en tant qu'adresses IP.

Autoriser les connexions sortantes suivantes. Pour chaque type de connexion, suivez le Link pour obtenir les adresses IP ou les domaines pour la région de votre workspace.

  • Application web Databricks : requise. Également utilisé pour les appels d’API REST à votre Workspace.

    Adresses IP et domaines pour les services et assets Databricks

  • Relais de connectivité sécurisée des clusters Databricks (SCC) : requis pour la connectivité sécurisée des clusters.

    Adresses IP et domaines pour les services et assets Databricks

  • URL globale AWS S3 : Requise par Databricks pour accéder au compartiment S3 racine. Utilisez s3.amazonaws.com:443, quelle que soit la région.

  • URL régionale AWS S3 : facultatif. Si vous utilisez des compartiments S3 qui pourraient se trouver dans d'autres régions, vous devez également autoriser l'endpoint régional S3. Bien qu'AWS fournisse un domaine et un port pour un endpoint régional (s3.<region-name>.amazonaws.com:443), Databricks recommande que vous utilisiez plutôt un endpoint Virtual Private Cloud (VPC) afin que ce trafic passe par le tunnel privé via le backbone du réseau AWS. Consultez (Recommandé) Configurer des Endpoint régionaux.

  • AWS STS global URL : Obligatoire. Utilisez l'adresse et le port suivants, quelle que soit la région : sts.amazonaws.com:443

  • URL régionale AWS STS : requise en raison du passage prévu vers un endpoint régional. Utilisez un endpoint Virtual Private Cloud (VPC). Voir (Recommandé) Configurer les Endpoint.

  • URL régionale AWS Kinesis : Obligatoire. L'Endpoint Kinesis est utilisé pour capturer les Logs nécessaires à la gestion et à la surveillance du logiciel. Pour l'URL de votre région, consultez Adresses Kinesis.

  • URL régionale du métastore RDS de la table (par région du plan de compute) : Obligatoire si votre Workspace Databricks utilise le Hive metastore default.

    Le Hive metastore se trouve toujours dans la même région que votre plan de compute, mais il peut se trouver dans une région différente de celle du plan de contrôle.

    Adresses RDS pour le Hive metastore hérité

remarque

Au lieu d'utiliser le default Hive metastore, vous pouvez choisir d'implémenter votre propre instance de metastore de table, auquel cas vous êtes responsable de son routage réseau.

Dépanner les Endpoint régionaux​

Si vous avez suivi les instructions ci-dessus et que les Endpoints Virtual Private Cloud (VPC) ne fonctionnent pas comme prévu, par exemple, si vos sources de données sont inaccessibles ou si le trafic contourne les Endpoints, vous pouvez utiliser l’une des deux approches pour ajouter le support des Endpoints régionaux pour S3 et STS au lieu d’utiliser des Endpoints Virtual Private Cloud (VPC).

  1. Ajoutez la variable d'environnement AWS_REGION dans la configuration du cluster et définissez-la sur votre région AWS. Pour l'activer pour tous les clusters, utilisez les règles de cluster. Vous avez peut-être déjà configuré cette variable d'environnement pour utiliser les montages DBFS.

  2. Ajoutez la configuration Apache Spark requise. Effectuez exactement l'une des approches suivantes :

    • Dans chaque notebook source :
Scala
%scala
spark.conf.set("fs.s3a.stsAssumeRole.stsEndpoint", "https://sts.<region>.amazonaws.com")
spark.conf.set("fs.s3a.endpoint", "https://s3.<region>.amazonaws.com")

  • Alternativement, dans la configuration Apache Spark pour le cluster :

    spark.hadoop.fs.s3a.endpoint https://s3.<region>.amazonaws.com
    spark.hadoop.fs.s3a.stsAssumeRole.stsEndpoint https://sts.<region>.amazonaws.com
  1. Si vous limitez la sortie du plan de compute classique à l'aide d'un pare-feu ou d'un appareil Internet, ajoutez ces adresses d'Endpoint régionales à votre liste d'autorisation.

Pour définir ces valeurs pour tous les clusters, configurez-les dans le cadre de votre règle de cluster.

(Facultatif) Accéder à S3 à l'aide de profils d'instance​

Pour accéder aux montages S3 à l'aide de profils d'instance, définissez les configurations Spark suivantes :

  • Soit **dans chaque notebook source** :
Scala
%scala
spark.conf.set("fs.s3a.stsAssumeRole.stsEndpoint", "https://sts.<region>.amazonaws.com")
spark.conf.set("fs.s3a.endpoint", "https://s3.<region>.amazonaws.com")

  • Ou dans la configuration Apache Spark du cluster :

    spark.hadoop.fs.s3a.endpoint https://s3.<region>.amazonaws.com
    spark.hadoop.fs.s3a.stsAssumeRole.stsEndpoint https://sts.<region>.amazonaws.com

Pour définir ces valeurs pour tous les clusters, configurez-les dans le cadre de votre règle de cluster.

attention

Pour le service S3, l'application de configurations d'Endpoint régionales supplémentaires au niveau du Notebook ou du cluster est soumise à des limitations. Notamment, l'accès à S3 interrégional est bloqué, même si l'URL S3 globale est autorisée dans votre pare-feu de sortie ou votre proxy. Si votre déploiement Databricks peut nécessiter un accès S3 inter-régions, il est important de ne pas appliquer la configuration Spark au niveau du notebook ou du cluster.

(Facultatif) Restreindre l’accès aux compartiments S3​

La plupart des lectures et écritures vers S3 sont autonomes au sein du plan de compute. Cependant, certaines opérations de gestion proviennent du plan de contrôle, qui est géré par Databricks. Pour limiter l'accès aux compartiments S3 à un ensemble spécifié d'adresses IP source, créez une politique de compartiment S3. Dans la politique du compartiment, incluez les adresses IP dans la liste aws:SourceIp. Si vous utilisez un Endpoint VPC, autorisez-y l'accès en l'ajoutant au aws:sourceVpce de la politique. Databricks utilise les ID de Virtual Private Cloud (VPC) pour accéder aux compartiments S3 dans la même région que le plan de contrôle Databricks, et les adresses IP NAT pour accéder aux compartiments S3 dans des régions différentes du plan de contrôle.

Pour plus d'informations sur les politiques de compartiment S3, consultez les exemples de politiques de compartiment dans la documentation Amazon S3. Des exemples de politiques de compartiment fonctionnels sont également inclus dans cette rubrique.

Exigences relatives aux politiques de compartiment​

Votre politique de compartiment doit répondre à ces exigences, pour vous assurer que vos clusters start correctement et que vous pouvez vous y connecter :

remarque

Lors du déploiement d'un nouveau Workspace avec des restrictions de politique de bucket S3, vous devez autoriser l'accès à la NAT-IP du plan de contrôle pour une région us-west, sinon le déploiement échouera. Une fois le Workspace déployé, vous pouvez supprimer les informations us-west et mettre à jour le NAT-IP du plan de contrôle pour refléter votre région.

Adresses IP et compartiments de stockage requis​

Pour les adresses IP et les domaines dont vous avez besoin pour configurer les politiques de compartiment S3 et les politiques d’Endpoint Virtual Private Cloud (VPC) afin de restreindre l’accès aux compartiments S3 de votre Workspace, consultez Adresses IP sortantes du plan de contrôle Databricks.

Exemples de politiques de compartiment​

Ces exemples utilisent du texte de remplacement pour indiquer où spécifier les adresses IP recommandées et les compartiments de stockage requis. Examinez les exigences pour vous assurer que vos clusters start correctement et que vous pouvez vous y connecter.

Restreignez l'accès au plan de contrôle Databricks, au plan de compute et aux adresses IP de confiance :

Cette politique de compartiment S3 utilise une condition Deny pour autoriser sélectivement l'accès depuis le plan de contrôle, la passerelle NAT et les adresses IP VPN d'entreprise que vous spécifiez. Remplacez le texte d'espace réservé par des valeurs pour votre environnement. Vous pouvez ajouter autant d'adresses IP que vous le souhaitez à la politique. Créez une politique par compartiment S3 que vous souhaitez protéger.

important

Si vous utilisez des Endpoint VPC, cette politique n'est pas complète. Voir Restreindre l'accès au plan de contrôle Databricks, aux Virtual Private Cloud (VPC) Endpoints et aux adresses IP fiables.

JSON
{
  "Sid": "IPDeny",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::<S3-BUCKET>", "arn:aws:s3:::<S3-BUCKET>/*"],
  "Condition": {
    "NotIpAddress": {
      "aws:SourceIp": ["<CONTROL-PLANE-NAT-IP>", "<DATA-PLANE-NAT-IP>", "<CORPORATE-VPN-IP>"]
    }
  }
}

Restreindre l'accès au plan de contrôle Databricks, aux Endpoint Virtual Private Cloud (VPC) et aux IP fiables :

Si vous utilisez un Endpoint VPC pour accéder à S3, vous devez ajouter une deuxième condition à la politique. Cette condition autorise l'accès depuis votre Endpoint Virtual Private Cloud (VPC) et ID Virtual Private Cloud (VPC) en l'ajoutant à la liste aws:sourceVpce.

Ce compartiment autorise sélectivement l’accès à partir de votre Endpoint Virtual Private Cloud (VPC), et à partir du plan de contrôle et des adresses IP VPN d’entreprise que vous spécifiez.

Lorsque vous utilisez des Endpoint Virtual Private Cloud (VPC), vous pouvez utiliser une stratégie d'Endpoint VPC au lieu d'une stratégie de compartiment S3. Une stratégie VPCE doit autoriser l'accès à votre compartiment S3 racine et au compartiment requis pour les artefacts, les logs et les datasets partagés pour votre région. Pour les adresses IP et les domaines de vos régions, consultez Adresses IP et domaines pour les services et assets Databricks.

Remplacez le texte de l'espace réservé par les valeurs de votre environnement.

JSON
{
  "Sid": "IPDeny",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::<S3-BUCKET>", "arn:aws:s3:::<S3-BUCKET>/*"],
  "Condition": {
    "NotIpAddressIfExists": {
      "aws:SourceIp": ["<CONTROL-PLANE-NAT-IP>", "<CORPORATE-VPN-IP>"]
    },
    "StringNotEqualsIfExists": {
      "aws:sourceVpce": "<VPCE-ID>",
      "aws:SourceVPC": "<VPC-ID>"
    }
  }
}
Sur cette page