Cette page explique les exigences et les options de configuration réseau du cluster Dataproc.
Conditions de connectivité Dataproc
Votre cluster Dataproc doit se trouver dans un réseau VPC qui répond aux exigences de routage et de pare-feu pour accéder de manière sécurisée aux API Google et à d'autres ressources.
Exigences concernant les itinéraires
L'agent Dataproc exécuté sur les VM du cluster a besoin d'un chemin d'accès à Internet pour accéder à l'API de contrôle Dataproc afin d'obtenir des tâches et de signaler l'état. Lors de leur création, les réseaux VPC contiennent une route par défaut générée par le système vers Internet. Il est déconseillé de supprimer la route par défaut vers Internet. Utilisez plutôt des pare-feu pour contrôler l'accès au réseau. Notez que les clusters à adresses IP internes uniquement ont également besoin de cette route par défaut vers Internet pour accéder aux API de contrôle Dataproc et à d'autres services Google, tels que Cloud Storage, mais leur trafic ne quitte pas les centres de données Google.
Exigences de pare-feu
Les machines virtuelles (VM) du cluster Dataproc doivent pouvoir communiquer entre elles à l'aide des protocoles ICMP, TCP (tous les ports) et UDP (tous les ports).
La règle de pare-feu du réseau VPC default
default-allow-internal
répond aux exigences de connectivité du cluster Dataproc et autorise l'entrée à partir de la plage de sources 10.128.0.0/9
de toutes les VM sur le réseau VPC comme suit:
Règle | Réseau | Direction | Priorité | Plage source | Protocoles:ports |
---|---|---|---|---|---|
default-allow-internal |
default |
entrée | 65534 |
10.128.0.0/9 |
tcp:0-65535 ,udp:0-65535 ,icmp |
Si vous supprimez la règle de pare-feu
default-allow-internal
, le trafic entrant sur le réseaudefault
est bloqué par la règle implicite d'entrée interdite.Si vous supprimez la règle de pare-feu
default-allow-internal
ou si vous n'utilisez pas le réseau VPCdefault
, vous devez créer votre propre règle qui répond aux exigences de connectivité de Dataproc, puis l'appliquer au réseau VPC de votre cluster.
Bonne pratique:créez une règle de pare-feu d'entrée pour votre réseau VPC de cluster qui n'autorise la connectivité entrante qu'entre les VM du cluster à l'aide d'une plage d'adresses IP source ou en identifiant les VM du cluster par tag réseau ou compte de service.
Créer une règle de pare-feu d'entrée
Si vous ou votre administrateur réseau ou de sécurité créez une règle de pare-feu d'entrée à appliquer à un réseau VPC de cluster Dataproc, elle doit présenter les caractéristiques suivantes:
Le paramètre sources spécifie les sources des paquets. Toutes les VM du cluster Dataproc doivent pouvoir communiquer entre elles. Vous pouvez identifier les VM du cluster par la plage d'adresses IP, les tags sources ou les comptes de service associés aux VM.
La cible de la règle doit identifier les VM du cluster. La cible peut être toutes les VM du réseau VPC, ou vous pouvez identifier des VM par plage d'adresses IP, tag cible ou compte de service cible.
La règle doit inclure les protocoles et ports suivants:
- TCP (tous les ports, 0 à 65 535)
- UDP (tous les ports, 0 à 65 535)
- ICMP
Dataproc utilise des services qui s'exécutent sur plusieurs ports. La spécification de tous les ports facilite l'exécution des services.
Diagnostiquer les règles de pare-feu VPC
Pour auditer les paquets non traités par des règles de pare-feu de priorité supérieure, vous pouvez créer deux règles de pare-feu de refus avec une faible priorité (65534). Contrairement aux règles de pare-feu implicites, vous pouvez activer la journalisation des règles de pare-feu pour chacune de ces règles de faible priorité :
Une règle de refus d'entrée (sources
0.0.0.0/0
, tous les protocoles, toutes les cibles du réseau VPC)Une règle de refus de sortie (destinations
0.0.0.0/0
, tous les protocoles, toutes les cibles du réseau VPC)
Grâce à ces règles de faible priorité et à la journalisation des règles de pare-feu, vous pouvez consigner les paquets non traités par des règles de pare-feu de priorité supérieure (et potentiellement plus spécifiques). Ces deux règles de faible priorité respectent également les bonnes pratiques de sécurité en mettant en œuvre une stratégie de "paquets supprimés" finale.
Examinez les journaux des règles de pare-feu pour déterminer si vous devez créer ou modifier des règles de priorité plus élevée afin d'autoriser les paquets. Par exemple, si des paquets envoyés entre les VM du cluster Dataproc sont supprimés, cela peut indiquer que vos règles de pare-feu doivent être ajustées.
Créer un réseau VPC
Au lieu d'utiliser le réseau VPC default
, vous pouvez créer votre propre réseau VPC en mode automatique ou personnalisé. Lorsque vous créez le cluster, vous associez votre réseau au cluster.
Environnement Assured Workloads:lorsque vous utilisez un environnement Assured Workloads pour la conformité réglementaire, le cluster, son réseau VPC et ses buckets Cloud Storage doivent être contenus dans l'environnement Assured Workloads.
Créer un cluster utilisant votre réseau VPC
Console
Sélectionnez votre réseau dans la section "Configuration du réseau" du panneau Personnaliser le cluster. Une fois le réseau choisi, le sélecteur Sous-réseau affiche le ou les sous-réseaux disponibles dans la région sélectionnée pour le cluster.
Google Cloud CLI
Utilisez gcloud dataproc clusters create
avec l'option ‑‑network
ou ‑‑subnet
pour créer un cluster sur un sous-réseau de votre réseau.
Si vous utilisez l'indicateur ‑‑network, le cluster utilisera un sous-réseau portant le même nom que le réseau spécifié dans la région où le cluster est créé.
--network example
. Étant donné que les réseaux automatiques sont créés avec des sous-réseaux dans chaque région, et que chaque sous-réseau reçoit le nom du réseau, vous pouvez transmettre le nom du réseau VPC en mode automatique à l'indicateur ‑‑network
.
Le cluster utilisera le sous-réseau VPC en mode automatique dans la région spécifiée avec l'option --region.
gcloud dataproc clusters create CLUSTER_NAME \ --network NETWORK_NAME \ --region=REGION \ ... other args ...
--subnet example
. Vous pouvez utiliser l'indicateur ‑‑subnet
pour créer un cluster qui utilise un sous-réseau de réseau VPC en mode automatique ou personnalisé dans la région du cluster. Spécifiez le chemin d'accès complet du sous-réseau.
gcloud dataproc clusters create CLUSTER_NAMEW \ --subnet projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME \ --region=REGION \ ... other args ...
API REST
Vous pouvez spécifier le champ networkUri ou subnetworkUri de la propriété GceClusterConfig
dans le cadre d'une requête clusters.create.
Exemple
POST /v1/projects/my-project-id/regions/us-central1/clusters/ { "projectId": "PROJECT_ID", "clusterName": CLUSTER_NAME, "config": { "configBucket": "", "gceClusterConfig": { "subnetworkUri": SUBNET_NAME, }, ...
Créer un cluster utilisant un réseau VPC dans un autre projet
Un cluster Dataproc peut utiliser un réseau VPC partagé défini dans un projet hôte. Le projet dans lequel le cluster Dataproc est créé est appelé projet de service.
Recherchez le numéro de projet du cluster Dataproc:
- Ouvrez la page Paramètres de IAM et administration dans la console Google Cloud. Sélectionnez le projet dans lequel vous allez créer le cluster Dataproc. Copiez l'ID du projet.
Un compte principal doté du rôle Administrateur de VPC partagé doit procéder comme suit. Consultez les instructions de configuration du VPC partagé pour obtenir des informations générales.
Assurez-vous que le projet hôte du VPC partagé est activé.
Associez le projet avec le cluster Dataproc au projet hôte.
Configurez le compte de service de l'agent de service Dataproc (
service-[project-number]@dataproc-accounts.iam.gserviceaccount.com
) pour qu'il dispose du rôle Utilisateur de réseau dans le projet hôte:Ouvrez la page IAM et administration dans la console Google Cloud.
Utilisez le sélecteur de projet pour sélectionner le nouveau projet hôte.
Cliquez sur Accorder l'accès.
Remplissez le formulaire d'octroi d'accès:
Ajouter des entités principales: saisissez le compte de service.
Attribuer des rôles: insérez "Compute Network" (Réseau Compute) dans la zone de filtre, puis sélectionnez le rôle Compute Network User (Utilisateur de réseau Compute).
Cliquez sur Enregistrer.
Une fois que le compte de service dispose du rôle
Network User
pour le projet hôte, créez un cluster qui utilise le réseau VPC partagé.
Créer un cluster qui utilise un sous-réseau VPC dans un autre projet
Un cluster Dataproc peut utiliser un sous-réseau VPC partagé défini dans un projet hôte. Le projet dans lequel le cluster Dataproc est créé est appelé projet de service.
Recherchez le numéro de projet du cluster Dataproc:
- Ouvrez la page Paramètres de IAM et administration dans la console Google Cloud. Sélectionnez le projet dans lequel vous allez créer le cluster Dataproc. Copiez l'ID du projet.
Un compte principal doté du rôle Administrateur de VPC partagé doit procéder comme suit. Consultez les instructions de configuration du VPC partagé pour obtenir des informations générales.
Assurez-vous que le projet hôte du VPC partagé est activé.
Associez le projet avec le cluster Dataproc au projet hôte.
Configurez le compte de service de l'agent de service Dataproc (
service-[project-number]@dataproc-accounts.iam.gserviceaccount.com
) pour qu'il dispose du rôle Utilisateur de réseau dans le projet hôte:Ouvrez la page Réseaux VPC dans la console Google Cloud.
Utilisez le sélecteur de projet pour sélectionner le projet hôte.
Cliquez sur le réseau contenant le sous-réseau que votre cluster Dataproc utilisera.
Sur la page Détails du réseau VPC, cochez la case à côté du nom du sous-réseau que votre cluster utilisera.
Si le panneau d'informations n'est pas ouvert, cliquez sur Afficher le panneau d'informations.
Pour chaque compte de service, procédez comme suit:
Dans le panneau d'informations, cliquez sur Ajouter un compte principal.
Remplissez le formulaire d'octroi d'accès:
Ajouter des entités principales: saisissez le compte de service.
Attribuer des rôles: insérez "Compute Network" (Réseau Compute) dans la zone de filtre, puis sélectionnez le rôle Compute Network User (Utilisateur de réseau Compute).
Cliquez sur Enregistrer.
Une fois que le compte de service dispose du rôle
Network User
pour le projet hôte, créez un cluster qui utilise le sous-réseau VPC partagé.
Créer un cluster Dataproc avec des adresses IP internes uniquement
Vous pouvez créer un cluster Dataproc isolé de l'Internet public dont les instances de VM communiquent via un sous-réseau IP privé (les VM du cluster ne sont pas attribuées d'adresses IP publiques). Pour ce faire, l'accès privé à Google doit être activé sur le sous-réseau afin de permettre aux nœuds du cluster d'accéder aux API et aux services Google, tels que Cloud Storage, à partir d'adresses IP internes.
Console
Vous pouvez créer un cluster Dataproc avec l'accès privé à Google activé à partir de la page Dataproc Créer un cluster dans la console Google Cloud. Cliquez sur Adresse IP interne uniquement dans le panneau Personnaliser le cluster pour activer cette fonctionnalité pour votre cluster.
CLI gcloud
Vous pouvez créer un cluster Dataproc avec des adresses IP internes en n'utilisant que la commande gcloud dataproc clusters create
avec l'option ‑‑no-address
.
Utiliser les options "--no-address" et "--network" : utilisez l'option ‑‑no-address
avec l'option ‑‑network
pour créer un cluster qui utilise un sous-réseau portant le même nom que le réseau de la région dans laquelle le cluster est créé.
gcloud dataproc clusters create CLUSTER_NAME \ --no-address \ --network NETWORK_NAME \ --region=REGION \ ... other args ...
Par exemple, les réseaux automatiques sont créés avec des sous-réseaux dans chaque région et portent le même nom que le réseau automatique. Vous pouvez ainsi transmettre le nom du réseau automatique à ‑‑network flag
pour créer un cluster qui utilise le sous-réseau automatique dans la région du cluster.
Utiliser les options "--no-address" et "--subnet" : utilisez l'option ‑‑no-address
avec les options ‑‑subnet
pour créer un cluster qui utilise un sous-réseau automatique ou personnalisé dans la région dans laquelle le cluster est créé. Transmettez à l'indicateur ‑‑subnet
le chemin d'accès complet à la ressource du sous-réseau.
gcloud dataproc clusters create cluster-name \ --no-address \ --subnet projects/project-id/regions/region/subnetworks/subnetwork-name \ --region=region \ ... other args ...
API REST
Vous pouvez définir le champ GceClusterConfig
internalIpOnly sur true
dans le cadre d'une requête clusters.create pour activer seulement les adresses IP internes.
Exemple :
POST /v1/projects/my-project-id/regions/us-central1/clusters/ { "projectId": "my-project-id", "clusterName": "example-cluster", "config": { "configBucket": "", "gceClusterConfig": { "subnetworkUri": "custom-subnet-1", "zoneUri": "us-central1-b", "internalIpOnly": true }, ...
Étant donné que, par défaut, les clusters associés à des adresses IP internes uniquement n'ont pas accès à Internet, les tâches qui téléchargent des dépendances sur Internet (par exemple, des tâches qui téléchargent des packages de dépendance Spark depuis Maven Central) échoueront. Il existe plusieurs solutions pour éviter ce problème :
Utilisez Cloud NAT pour autoriser l'accès du cluster à Internet.
Créez une image personnalisée incluant les dépendances (par exemple, les packages de dépendance Spark dans
/usr/lib/spark/jars/
).Chargez les dépendances dans un bucket Cloud Storage, puis utilisez une action d'initialisation pour télécharger les dépendances du bucket lors de la création du cluster.
Réseaux Dataproc et VPC Service Controls
VPC Service Controls permet aux administrateurs de définir un périmètre de sécurité autour des ressources des services gérés par Google afin de contrôler les communications avec et entre ces services.
Notez les limites et stratégies suivantes lorsque vous utilisez des réseaux VPC Service Controls avec des clusters Dataproc:
Pour installer des composants en dehors du périmètre VPC Service Controls, créez une image personnalisée Dataproc qui pré-installe les composants, puis créez le cluster à l'aide de l'image personnalisée.
Consultez la page Procédures spéciales de protection de Dataproc à l'aide de VPC Service Controls.