VPC Service Controls : protection du service de transfert de données BigQuery

1. Introduction

Dans cet atelier, vous allez découvrir comment protéger le service de transfert de données BigQuery à l'aide de VPC Service Controls lorsque vous transférez des données de Cloud Storage vers un ensemble de données BigQuery. Nous protégeons ensuite Cloud Storage et répétons le processus pour transférer les données de Cloud Storage vers BigQuery. La protection de Cloud Storage entraîne une violation de VPC Service Controls, qui doit être corrigée pour que le transfert aboutisse. Enfin, nous protégeons également BigQuery, puis essayons de copier un ensemble de données entre des projets, ce qui entraîne également une infraction qui doit être corrigée.

Tout au long de cet atelier, nous verrons comment corriger les cas de non-respect des règles d'entrée et de sortie à l'aide de règles d'entrée et de sortie, respectivement. Nous utiliserons également un niveau d'accès pour corriger l'infraction d'entrée du service de transfert de données BigQuery. Les objectifs de cet atelier de programmation sont les suivants:

• Découvrez comment corriger les cas de non-respect des règles d'entrée et de sortie à l'aide de règles d'entrée et de sortie respectivement dans différents services, notamment Cloud Storage, BigQuery et le service de transfert de données BigQuery.
• comprendre pourquoi une infraction spécifique s'est produite ;

2. Configuration et exigences concernant les ressources

Avant de commencer

Dans cet atelier de programmation, nous partons du principe que vous savez déjà:

• Créer un dossier
• Créer un projet dans un dossier ou déplacer un projet existant dans un dossier
• Créer une règle d'accès limitée
• Créer et configurer un périmètre de service dans la console Google Cloud
• Rechercher des journaux d'infractions à partir des journaux d'audit

Ces conditions préalables ont été abordées dans d'autres ateliers de programmation sur VPC Service Controls: Tutoriel de base sur VPC Service Controls I et Tutoriel de base sur VPC Service Controls II – Résoudre les problèmes de non-respect des règles d'exportation.

Configuration

Notre configuration initiale est conçue comme suit:

• Une organisation Google Cloud
• Un dossier sous "Organisation". Pour cet atelier de programmation, nous l'appellerons codelab-folder.
• Deux projets Google Cloud dans le dossier codelab-folder. Pour cet atelier de programmation, nous appelons les projets project-1 et project-2.
  • Si vous n'avez pas encore créé le dossier et les projets, dans la console Google Cloud, créez un dossier sous l'organisation et deux projets.
• Autorisations requises: Rôles IAM pour gérer les dossiers, Rôles IAM pour gérer les projets, Rôles IAM requis pour configurer VPC Service Controls, Rôles IAM pour gérer BigQuery et Rôles IAM pour gérer Cloud Storage.
• Compte de facturation des projets project-1 et project-2.

Pour cet atelier de programmation, vous pouvez vous attribuer les rôles prédéfinis suivants: Administrateur de dossier et Créateur de projet (au niveau du dossier), Propriétaire (au niveau du projet), Administrateur BigQuery (au niveau du projet), Administrateur d'objets de stockage (au niveau du projet) et Administrateur Access Context Manager (au niveau de l'organisation). Vous disposerez ainsi des rôles requis pour configurer les ressources nécessaires à l'ensemble de cet atelier de programmation.

Créer une règle limitée et un périmètre de service standard

Dans cet atelier de programmation, nous allons utiliser un périmètre de service standard protégeant project-2.

• Créez une règle d'accès limitée, qui est limitée au niveau du dossier codelab-folder. Pour cet atelier de programmation, nous supposons que la règle d'accès créée a l'ID 987654321.
• Créez un périmètre standard, que nous appellerons perimeter-2, et ajoutez le projet project-2.

Dans le périmètre perimeter-2, limitez BigQuery Data Transfer API.

Création d'un bucket Cloud Storage et d'un ensemble de données BigQuery

Pour les besoins de cet atelier de programmation, n'importe quel fichier CSV suffit, quel que soit son contenu. La principale limitation concerne l'exigence de colocalisation, qui impose les conditions suivantes:

• Si votre ensemble de données BigQuery se trouve dans une zone multirégionale, le bucket Cloud Storage contenant les données que vous transférez doit se trouver dans la même zone multirégionale ou dans un emplacement inclus dans la zone multirégionale.
• Si votre ensemble de données se trouve dans une région, votre bucket Cloud Storage doit se situer dans la même région.

Par la suite, pour cet atelier de programmation, nous nous assurerons que le bucket Cloud Storage et l'ensemble de données BigQuery se trouvent dans la même région ou la même zone multirégionale.

Créer un bucket Cloud Storage dans le projet project-1

Pour cet atelier de programmation, nous utiliserons Cloud Storage comme source de données, qui est une source de données compatible avec le service de transfert de données BigQuery.

Pour créer un bucket Cloud Storage, suivez la procédure de création d'un bucket.

• Saisissez un nom qui répond aux exigences de dénomination des buckets. Pour cet atelier de programmation, nous appellerons le bucket codelab-bqtransfer-bucket.
• Pour l'emplacement de stockage des données, sélectionnez un type d'emplacement et un emplacement où les données du bucket seront stockées de manière permanente. Pour cet atelier de programmation, nous utiliserons us (plusieurs régions aux États-Unis).

Créer un fichier CSV

Si vous disposez déjà d'un exemple de fichier CSV, vous pouvez ignorer cette étape.

Depuis votre machine locale ou à l'aide de Cloud Shell, vous pouvez utiliser la commande echo pour créer un exemple de fichier CSV, codelab-test-file.csv, à l'aide des commandes suivantes:

echo "name,age" > codelab-test-file.csv; \
echo "Alice,10" >> codelab-test-file.csv; \
echo "Bob,20" >> codelab-test-file.csv; \
echo "Carol,30" >> codelab-test-file.csv; \
echo "Dan,40" >> codelab-test-file.csv; \
echo "Eve,50" >> codelab-test-file.csv; \
echo "Frank,60" >> codelab-test-file.csv; \
echo "Grace,70" >> codelab-test-file.csv; \
echo "Heidi,80" >> codelab-test-file.csv;

Importer un fichier CSV dans un bucket Cloud Storage

Une fois le fichier CSV créé, exécutez la commande suivante pour importer l'objet de fichier dans le bucket créé:

gcloud storage cp codelab-test-file.csv gs://codelab-bqtransfer-bucket

Pour vérifier que le fichier a été importé dans le bucket créé, listez les objets du bucket ou exécutez la commande suivante:

gcloud storage ls --recursive gs://codelab-bqtransfer-bucket/**

Créer un ensemble de données et une table BigQuery dans project-2

1. Créez un ensemble de données BigQuery dans le projet project-2 en suivant ces étapes.
   1. Pour ID de l'ensemble de données, indiquez un nom d'ensemble de données unique. Pour cet atelier de programmation, nous utilisons: codelab_bqtransfer_dataset.
   2. Dans Type d'emplacement, sélectionnez un emplacement géographique pour l'ensemble de données. Pour cet atelier de programmation, nous utilisons le même emplacement que le bucket Cloud Storage: États-Unis (plusieurs régions).
2. Créez une table BigQuery sous l'ensemble de données codelab_bqtransfer_dataset créé en suivant ces étapes.
   1. Dans la section Source, sélectionnez Table vide dans la liste Créer une table à partir de.
   2. Dans le champ Table, saisissez le nom de la table que vous souhaitez créer. Pour cet atelier de programmation, nous utilisons le nom codelab-bqtransfer-table.
   3. Vérifiez que le champ Type de table est défini sur Table native.
   4. Dans la section Schéma, saisissez la définition du schéma. Vous pouvez saisir des informations de schéma en cliquant sur Modifier sous forme de texte, puis en saisissant le schéma suivant, qui est conforme au format du fichier CSV créé.

   [{
   "name": "name",
   "type": "STRING",
   "mode": "NULLABLE",
   "description": "The name"
   },
   {
   "name": "age",
   "type": "INTEGER",
   "mode": "NULLABLE",
   "description": "The age"
   }]
   

Coût

Vous devez activer la facturation dans les projets project-2 et project-1 pour utiliser les ressources/API Cloud. Nous vous conseillons d'arrêter les ressources utilisées pour éviter qu'elles ne vous soient facturées au-delà de cet atelier de programmation.

Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300 $.

Les ressources qui génèrent ces coûts sont BigQuery et Cloud Storage. Vous trouverez un coût estimé dans le simulateur de prix BigQuery et le simulateur de prix Cloud Storage.

3. Configurer le transfert de données d'un objet Cloud Storage vers une table BigQuery

Nous allons maintenant essayer de créer un service de transfert de données (dans project-2) pour transférer des données de Cloud Storage (situé dans project-1) vers BigQuery (situé dans project-2), tout en protégeant le service de transfert de données BigQuery dans project-2 à l'aide des contrôles de service VPC. Si vous ne protégez que le service de transfert de données BigQuery (sans protéger BigQuery et Cloud Storage), les principaux ne peuvent créer et gérer que des transferts de données (par exemple, démarrer manuellement un transfert de données).

Configurer le transfert de données depuis Cloud Storage

Pour créer un transfert de données, procédez comme suit:

1. Accédez à la page BigQuery de la console Google Cloud de project-2.
2. Cliquez sur Transferts de données.

Une violation de VPC Service Controls devrait se produire, car le périmètre perimeter-2 protège le service de transfert de données BigQuery dans project-2. L'accès doit être autorisé par VPC Service Controls avant de pouvoir configurer le transfert de données.

Examiner le non-respect lors de l'accès à la page "Transferts de données"

Dans la console Google Cloud, nous pouvons voir l'identifiant unique de VPC Service Controls. Utilisez le même identifiant pour filtrer les journaux et identifier les détails de l'infraction (remplacez OBSERVED_VPCSC_DENIAL_UNIQUE_ID par l'ID de refus observé):

protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="OBSERVED_VPCSC_DENIAL_UNIQUE_ID"

La non-conformité observée est une NO_MATCHING_ACCESS_LEVEL, c'est-à-dire une violation d'entrée avec des détails semblables à ceux-ci:

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
}]
violationReason: "NO_MATCHING_ACCESS_LEVEL"
callerIp: "USER_PUBLIC_IP_ADDRESS"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.ListTransferConfigs"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}

L'accès à la page "Transferts de données" tente de lister tous les transferts de données configurés. Il s'agit donc d'une violation de la méthode ListTransferConfigs.

Résoudre le cas de non-respect pour le service bigquerydatatransfer.googleapis.com

Vous pouvez utiliser un niveau d'accès ou une règle d'entrée pour corriger une violation d'entrée. Dans cet atelier de programmation, utilisons une règle d'entrée configurée avec l'identité utilisateur refusée, qui permet d'accéder au service bigquerydatatransfer.googleapis.com et à toutes les méthodes.

Une fois la règle d'entrée en place, l'accès à la page Transferts de données devrait fonctionner sans problème.

Reprendre la configuration du transfert de données depuis Cloud Storage

Sur la page "Transferts de données" (après avoir cliqué sur "Transferts de données"), procédez comme suit:

1. Cliquez sur + Créer un transfert.
2. Dans la section Source type (Type de source), choisissez Google Cloud Storage comme Source.
3. Dans la section Transfer config name (Nom de la configuration de transfert), sous Display name (Nom à afficher), saisissez un nom pour le transfert, tel que Codelab Transfer.
4. Dans la section Options de programmation:
   1. Sélectionnez une fréquence de répétition, par exemple 15 minutes.
   2. Veillez à sélectionner Démarrer maintenant. Sinon, le transfert de données ne commencera qu'après la fréquence de répétition configurée.
5. Dans la section Destination settings (Paramètres de destination), pour le champ Destination dataset (Ensemble de données de destination), choisissez l'ensemble de données que vous avez créé pour stocker vos données: codelab_bqtransfer_dataset
6. Dans la section Détails de la source de données :
   1. Sous Destination table (Table de destination), saisissez le nom de votre table de destination. Le nom de la table de destination doit respecter les règles de dénomination des tables. Pour cet atelier de programmation, nous utiliserons la table que nous avons créée précédemment: codelab-bqtransfer-table
   2. Dans le champ Cloud Storage URI (URI Cloud Storage), saisissez l'URI Cloud Storage. Pour cet atelier de programmation, nous utilisons le bucket et le fichier créés: codelab-bqtransfer-bucket/codelab-test-file.csv
   3. Pour Préférence d'écriture, conservez APPEND (ou choisissez MIRROR).
   4. NE PAS sélectionner l'option de suppression des fichiers après le transfert (car nous réutiliserons le même fichier plusieurs fois). Vous pouvez toutefois utiliser plusieurs fichiers et supprimer les fichiers sources après le transfert.)
   5. Pour Format de fichier, sélectionnez CSV.
   6. Dans Options de transfert, sous CSV, saisissez la virgule(",") comme Délimiteur de champ.
7. Dans le menu Compte de service, sélectionnez un compte de service parmi ceux associés à votre projet Google Cloud.
   1. Le compte de service sélectionné doit disposer des autorisations requises pour Cloud Storage dans le projet hébergeant le bucket de stockage (project-1 dans cet atelier de programmation).
   2. Pour cet atelier de programmation, nous utiliserons un compte de service créé dans project-2 sous le nom [e-mail].
8. Cliquez sur Enregistrer.

Étant donné que nous avons sélectionné Démarrer maintenant comme option de planification, le premier transfert commencera dès que vous sélectionnerez Enregistrer.

Le compte de service spécifié dans la configuration du transfert de données sera utilisé pour accéder à l'objet de bucket Cloud Storage. Pour chaque tentative de transfert de données, les journaux dans project-1 (le projet source) doivent afficher une entrée de journal du compte de service effectuant l'appel storage.objects.get (serviceName: "storage.googleapis.com") sur l'objet transféré. En revanche, lorsque vous examinez les journaux dans project-2, qui héberge la table BigQuery de destination, vous constaterez que l'agent du service de transfert de données BigQuery est celui qui écrit les données (serviceName: 'bigquery.googleapis.com') de l'objet de stockage dans la table BigQuery spécifiée.

Vérifier l'état du service de transfert de données

Pour vérifier l'état du transfert de données configuré:

• Accédez à la page BigQuery de la console Google Cloud.
• Cliquez sur Transferts de données.
• La liste des transferts configurés s'affiche.

Cliquez sur Codelab Transfer (sous "Nom à afficher") pour afficher la liste de toutes les exécutions effectuées jusqu'à présent.

L'exécution du transfert de données devrait aboutir, sans violation de VPC Service Controls pour le transfert de données déclenché manuellement et planifié. Notez que seul le transfert déclenché manuellement a besoin de la règle d'entrée pour autoriser l'accès à l'entité principale qui lance le transfert manuellement.

4. Restrictions liées aux adresses IP pour les transferts de données déclenchés manuellement

Les règles d'entrée actuellement configurées permettent à l'identité configurée de déclencher manuellement le transfert de données à partir de n'importe quelle adresse IP.

L'utilisation du niveau d'accès permet à VPC Service Controls de limiter l'accès autorisé en fonction de attributs spécifiques de requêtes API, notamment:

• Sous-réseaux IP: vérifie si la requête provient d'une adresse IP spécifique.
• Régions: vérifie si la requête provient d'une région spécifique, déterminée par la géolocalisation de l'adresse IP.
• Principals: vérifie si la requête provient d'un compte spécifique.
• Stratégie d'appareil: vérifie si la requête provient d'un appareil qui répond à des exigences spécifiques.

Pour appliquer la vérification de ces attributs avec la règle d'entrée déjà configurée, nous devons créer un niveau d'accès qui autorise les attributs souhaités, puis ajouter ce niveau d'accès en tant que source dans la règle d'entrée.

Ce diagramme illustre l'accès initié par les deux principaux ([e-mail] et [e-mail]) dans trois scénarios, montrant comment VPC Service Controls évalue les sources (niveau d'accès à l'entrée) et les attributs d'identité en tant que condition AND, où les deux doivent correspondre.

1. L'utilisateur [e-mail] est autorisé à accéder à l'application lorsqu'il tente d'y accéder à partir d'une adresse IP autorisée par le niveau d'accès, car son adresse IP et son compte utilisateur correspondent aux configurations de la règle d'entrée.
2. L'accès de l'utilisateur [e-mail] est bloqué lorsque son adresse IP ne correspond pas à l'adresse IP autorisée, même si son compte est celui configuré dans la règle d'entrée.
3. L'accès de l'utilisateur [e-mail] est bloqué, même s'il tente d'accéder à partir d'une adresse IP autorisée, car son compte n'est pas autorisé par la règle d'entrée.

Créer un niveau d'accès

Pour créer un niveau d'accès qui limite l'accès par adresse IP:

1. Ouvrez la page Access Context Manager dans la console Google Cloud.
   • Si vous y êtes invité, sélectionnez le dossier codelab-folder.
2. En haut de la page Access Context Manager, cliquez sur CRÉER UN NIVEAU D'ACCÈS.
3. Dans le volet Nouveau niveau d'accès, attribuez un titre au nouveau niveau d'accès. Pour cet atelier de programmation, nous l'appellerons project_2_al.
4. Dans la section Conditions, cliquez sur + devant Sous-réseaux IP.
5. Dans le champ IP Subnetworks (Sous-réseaux IP), sélectionnez Public IP (Adresse IP publique).
   • Vous pouvez également sélectionner l'option "Adresse IP privée" pour utiliser une adresse IP interne dans les niveaux d'accès. Toutefois, pour cet atelier de programmation, nous utilisons une adresse IP publique.
   • Saisissez une ou plusieurs plages IPv4 ou IPv6 sous forme de blocs CIDR.

Les journaux de non-respect des règles VPC Service Controls indiquent l'adresse IP publique de l'utilisateur, sauf si l'accès a été effectué à partir d'une instance Compute Engine sans adresse IP externe.

Ajouter un niveau d'accès dans la règle d'entrée

Dans la règle d'entrée, le niveau d'accès est référencé dans le champ sources, qui est un champ obligatoire, comme indiqué dans la documentation de référence sur les règles d'entrée. Pour autoriser l'entrée aux ressources, VPC Service Controls évalue les attributs sources et identityType en tant que condition AND. La règle d'entrée utilise l'identité de l'entité principale déclenchant manuellement le transfert de données, et non le compte de service spécifié dans la configuration du transfert de données.

Réexécuter le transfert avec les configurations limitant l'accès par adresse IP

Pour évaluer l'efficacité des configurations appliquées, déclenchez à nouveau le transfert à l'aide des scénarios suivants:

• à l'aide de l'adresse IP de la plage autorisée dans le niveau d'accès référencé par la règle d'entrée.
• en utilisant une adresse IP non autorisée par les configurations ;

L'accès à partir d'une adresse IP autorisée doit aboutir, tandis que l'accès à partir d'une adresse IP non autorisée doit échouer et entraîner une violation de VPC Service Controls.

Pour tester facilement avec une autre adresse IP, autorisez l'adresse IP attribuée lorsque vous utilisez la console Google Cloud, puis effectuez le test avec Cloud Shell.

Dans Cloud Shell, exécutez la commande suivante pour déclencher manuellement un transfert, en remplaçant RUN_TIME et RESOURCE_NAME:

bq mk \
  --transfer_run \
  --run_time='RUN_TIME' \
  RESOURCE_NAME

Par exemple, l'exemple de commande suivant s'exécute immédiatement pour une configuration de transfert 12345678-90ab-cdef-ghij-klmnopqrstuv dans le projet 1234567890.

NOW=$(TZ=GMT date +"%Y-%m-%dT%H:%M:%SZ");
bq mk \
  --transfer_run \
  --run_time=$NOW \
  projects/1234567890/locations/us/transferConfigs/12345678-90ab-cdef-ghij-klmnopqrstuv

Le résultat observé indique une violation de VPC Service Controls, comme prévu, car l'adresse IP n'est pas autorisée.

L'infraction observée concerne la méthode DataTransferService.StartManualTransferRuns.

ingressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
targetResource: "projects/[PROJECT2_NUMBER]"
targetResourcePermissions: [0: "vpcsc.permissions.unavailable"]
}]
violationReason: "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"
resource: {
labels: {
method: "google.cloud.bigquery.datatransfer.v1.DataTransferService.StartManualTransferRuns"
project_id: "project-2"
service: "bigquerydatatransfer.googleapis.com"
}
type: "audited_resource"
}
severity: "ERROR"

5. Démarrer le transfert de données tout en protégeant le service Cloud Storage

Comme nous effectuons un transfert de Cloud Storage vers BigQuery, ajoutons Cloud Storage aux services protégés par VPC Service Controls et voyons si le transfert reste efficace.

Dans la configuration perimeter-2, ajoutez l'API Cloud Storage comme l'un des services restreints, ainsi que l'API BigQuery Data Transfer.

Après avoir sécurisé l'API Cloud Storage, attendez le prochain transfert de données planifié ou déclenchez manuellement un transfert en procédant comme suit:

1. Accédez à la page "BigQuery" de la console Google Cloud.
2. Cliquez sur Transferts de données.
3. Sélectionnez votre transfert dans la liste: pour cet atelier de programmation, nous utilisons le transfert Codelab Transfer.
4. Cliquez sur Exécuter le transfert maintenant.
5. Cliquez sur OK.

Un autre transfert sera lancé. Vous devrez peut-être actualiser la page pour le voir. Cette fois, le transfert échouera en raison d'un non-respect de VPC Service Controls.

Examiner un cas de non-respect de VPC Service Controls dans Cloud Storage

Filtrez les journaux d'audit à l'aide de vpcServiceControlsUniqueIdentifier, comme indiqué dans le résumé du transfert.

La non-conformité observée est une violation de sortie RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER avec les détails suivants:

• Le principal est le compte de service configuré dans le service de transfert de données (que le transfert de données soit déclenché manuellement ou exécuté selon un calendrier, le principal refusé sera le même).
• Le service concerné est Cloud Storage
• La source de la requête est le projet dans lequel le service de transfert de données est configuré: project-2
• Le projet cible est celui dans lequel se trouve l'objet Cloud Storage: project-1

principalEmail: "[e-mail]"
egressViolations: [
0: {
servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
source: "projects/[PROJECT2_NUMBER]"
sourceType: "Resource"
targetResource: "projects/[PROJECT1_NUMBER]"
targetResourcePermissions: [0: "storage.objects.get"]
}]
labels: {
method: "google.storage.objects.get"
project_id: "project-2"
service: "storage.googleapis.com"
}

Résoudre le problème de non-respect des limites de sortie Cloud Storage

Pour corriger l'infraction de sortie, nous devons utiliser une règle de sortie qui autorise le trafic du compte de service refusé vers le projet avec des objets Cloud Storage.

Après avoir modifié le périmètre de service perimeter-2, répétez le processus pour déclencher à nouveau le transfert. Aucun message d'erreur ne s'affichera.

6. Copier un ensemble de données BigQuery de project-2 vers project-1

Après avoir confirmé que nous pouvons transférer des données du compartiment Cloud Storage dans project-1 vers l'ensemble de données BigQuery dans project-2, copions l'ensemble de données BigQuery de project-2 vers project-1, tandis que l'API BigQuery est protégée par les contrôles de service VPC.

Pour créer et copier l'ensemble de données, nous allons utiliser la commande bq mk, qui utilise l'outil bq.

BigQuery utilise le service de transfert de données BigQuery dans le backend pour copier les ensembles de données.

Créer un ensemble de données de destination dans project-1

Avant de copier l'ensemble de données, vous devez d'abord créer l'ensemble de données de destination. Pour créer l'ensemble de données de destination, nous pouvons exécuter la commande suivante, qui crée un ensemble de données nommé copied_dataset, dans le projet project-1 avec us comme emplacement.

bq mk \
  --dataset \
  --location=us \
  project-1:copied_dataset

Protéger le service BigQuery dans project-2 avec VPC Service Controls

Modifiez la configuration du périmètre perimeter-2 et ajoutez l'API BigQuery comme service protégé, ainsi que les services BigQuery Data Transfer et Cloud Storage.

Lancer la copie de l'ensemble de données

Pour copier l'ensemble de données, exécutez la commande bq mk suivante, qui copie l'ensemble de données codelab_bqtransfer_dataset du projet project-2 vers l'ensemble de données copied_dataset dans project-1, et écrase le contenu de l'ensemble de données, le cas échéant.

bq mk \
  --transfer_config \
  --project_id=project-1 \
  --target_dataset=copied_dataset \
  --data_source=cross_region_copy \
  --display_name='Dataset from project-2 to project-1' \
  --params='{
     "source_dataset_id":"codelab_bqtransfer_dataset",
     "source_project_id":"project-2",
     "overwrite_destination_table":"true"
     }'

La commande s'exécute correctement. En attendant, la configuration de transfert est créée pour lancer l'opération de copie de l'ensemble de données. La copie du jeu de données lui-même échouera, car il s'agit d'un cas de non-respect de VPC Service Controls.

Pour obtenir les détails du non-respect de VPC Service Controls correspondant, consultez les journaux dans project-2 (projet d'ensemble de données source) à l'aide de la requête de journal suivante. La requête de journal filtre les journaux sur le service BigQuery et le nom de la ressource de l'ensemble de données en cours de copie (codelab_bqtransfer_dataset).

resource.labels.service="bigquery.googleapis.com"
protoPayload.metadata.resourceNames:"datasets/codelab_bqtransfer_dataset"

Le non-respect de VPC Service Controls observé est un cas de sortie de project-2 vers project-1.

egressViolations: [
  0: {
   servicePerimeter: "accessPolicies/987654321/servicePerimeters/perimeter-2"
   source: "projects/[PROJECT-2-NUMBER]"
   sourceType: "Resource"
   targetResource: "projects/[PROJECT-1-NUMBER]"
   targetResourcePermissions: [
     0: "bigquery.transfers.update"
     1: "bigquery.transfers.get"
     2: "bigquery.jobs.create"
     ]
   }
]
method: "bigquery.tables.getData"
service: "bigquery.googleapis.com"

Corriger toutes les infractions BigQuery et relancer la copie de l'ensemble de données

Lorsque vous effectuez une copie d'un ensemble de données BigQuery entre des projets qui ne font pas partie du même périmètre de service, la règle d'entrée/de sortie doit actuellement autoriser toutes les méthodes pour que le processus fonctionne. Ce comportement est susceptible d'évoluer à l'avenir. Vous pouvez suivre les mises à jour dans le outil de suivi des problèmes publics.

Pour corriger l'infraction de sortie, nous devons créer une règle de sortie qui autorise le principal refusé. Le compte principal refusé est celui qui exécute la commande mk.

Une fois la règle de sortie en place, exécutez la même commande sur le perimeter-2 de périmètre pour copier l'ensemble de données. Cette fois, le jeu de données devrait être copié sans violation de VPC Service Controls.

7. Nettoyage

Bien que l'utilisation de VPC Service Controls ne fasse pas l'objet d'une facturation distincte lorsque le service n'est pas utilisé, il est recommandé de nettoyer la configuration utilisée dans cet atelier. Vous pouvez également supprimer l'instance de VM et/ou les projets Cloud pour éviter que des frais ne vous soient facturés. La suppression du projet Cloud arrête la facturation de toutes les ressources utilisées dans ce projet.

• Pour supprimer le bucket Cloud Storage, procédez comme suit:
  • Dans la console Google Cloud, accédez à la page Buckets Cloud Storage.
  • Cochez la case du bucket à supprimer, puis cliquez sur Supprimer.
  • Dans la fenêtre qui apparaît en superposition, confirmez que vous souhaitez supprimer le bucket et son contenu.
• Pour supprimer l'ensemble de données BigQuery, procédez comme suit:
  • Dans la console Google Cloud, accédez à la page BigQuery.
  • Dans le volet Explorateur, développez votre projet et sélectionnez un ensemble de données.
  • Développez le menu à trois points, puis cliquez sur Supprimer.
  • Dans la boîte de dialogue Supprimer l'ensemble de données, saisissez delete dans le champ, puis cliquez sur Supprimer.
• Pour supprimer le périmètre de service, procédez comme suit:
  • Dans la console Google Cloud, sélectionnez Sécurité, puis VPC Service Controls au niveau auquel la règle d'accès est limitée, dans ce cas, au niveau du dossier.
  • Sur la page "VPC Service Controls" (Contrôles des services VPC), dans la ligne du tableau correspondant au périmètre que vous souhaitez supprimer, sélectionnez Delete Icon.
• Pour supprimer le niveau d'accès, procédez comme suit:
  • Dans la console Google Cloud, ouvrez la page Access Context Manager au niveau du champ d'application "Dossier".
  • Dans la grille, identifiez la ligne du niveau d'accès que vous souhaitez supprimer, sélectionnez le menu à trois points, puis Supprimer.
• Pour arrêter les projets, procédez comme suit:
  • Dans la console Google Cloud, accédez à la page Paramètres IAM et administration du projet que vous souhaitez supprimer.
  • Sur la page "IAM et administration", sélectionnez Arrêter.
  • Saisissez l'ID du projet, puis sélectionnez Arrêter quand même.

8. Félicitations !

Dans cet atelier de programmation, vous avez créé un périmètre VPC Service Controls, l'avez appliqué et l'avez dépanné.

En savoir plus

Vous pouvez également explorer les scénarios suivants:

• Ajoutez project-1 dans un périmètre différent qui protège également BigQuery, le service de transfert de données BigQuery et Cloud Storage.
• Effectuez le transfert de données BigQuery à partir d'autres sources compatibles.
• Limitez l'accès des utilisateurs en fonction d'autres attributs, comme la zone géographique ou la stratégie de l'appareil.

Licence

Ce document est publié sous une licence Creative Commons Attribution 2.0 Generic.