Partager des règles VPC Service Controls
Ce document décrit les règles d'entrée et de sortie dont vous avez besoin pour permettre aux éditeurs et aux abonnés du partage BigQuery (anciennement Analytics Hub) d'accéder aux données des projets comportant des périmètres VPC Service Controls. Ce document part du principe que vous maîtrisez les périmètres VPC Service Controls, les ensembles de données partagés, les échanges de données, les fiches et les ensembles de données associés.
Un projet appelant est le projet réseau ou client Google Cloud qui lance la requête, tel qu'une requête SQL ou une commande Google Cloud CLI.
Créer un échange de données
Dans le schéma suivant, les projets contenant l'échange de données et l'ensemble de données partagé se trouvent dans des périmètres de service différents :
Figure 1 : Règles VPC Service Controls permettant de créer un échange de données
Dans la figure 1, les composants suivants associés à des libellés :
- Appelant : administrateur BigQuery Sharing.
- Projet R : projet appelant.
- Projet E : héberge l'échange de données et les fiches.
En tant qu'administrateur du partage BigQuery, lorsque vous créez un échange de données dans un projet différent du projet appelant, vous devez ajouter les règles d'entrée et de sortie suivantes :
| Projet | Règle |
|---|---|
| Projet R | Règle de sortie pour le projet E |
| Projet E (échange de données) | Règle d'entrée pour le projet R |
Création d'une fiche
Dans le schéma suivant, les projets contenant l'échange de données et l'ensemble de données partagé se trouvent dans des périmètres de service différents :
Figure 2. Règles VPC Service Controls permettant de créer une liste
Dans la figure 2, les composants suivants sont associés à des libellés :
- Appelant : administrateur ou éditeur BigQuery Sharing.
- Projet R : projet appelant.
- Projet E : héberge l'échange de données et les fiches.
- Projet S : héberge l'ensemble de données partagé.
Lorsque vous créez une fiche dans un échange de données qui se trouve dans un projet différent de celui de l'ensemble de données partagé, vous devez ajouter les règles d'entrée et de sortie suivantes pour permettre aux éditeurs BigQuery Sharing de créer une fiche :
| Projet | Règle |
|---|---|
| Projet R |
Règle de sortie pour le projet E Règle de sortie pour le projet S |
| Projet E (échange de données) |
Règle de sortie pour le projet S Règle d'entrée pour le projet R |
| Projet S (ensemble de données partagé) |
Règle de sortie pour le projet E Règle d'entrée pour le projet R |
S'abonner à une fiche
Dans le schéma suivant, les projets contenant la liste et l'ensemble de données associé pour cette liste se trouvent dans des périmètres de service différents :
Figure 3. Règles de VPC Service Controls pour s'abonner à une liste
Dans la figure 3, les composants suivants sont associés à des libellés :
- Appelant : abonné à BigQuery Sharing.
- Projet R : projet appelant.
- Projet E : héberge l'échange de données et les fiches.
- Projet L : héberge l'ensemble de données associé.
En tant qu'abonné au partage BigQuery, lorsque vous vous abonnez à une fiche dans un échange de données se trouvant dans un projet différent de votre projet, vous devez ajouter les règles d'entrée et de sortie suivantes :
| Projet | Règle |
|---|---|
| Projet R |
Règle de sortie pour le projet E Règle de sortie pour le projet L |
| Projet E (liste) |
Règle de sortie pour le projet L Règle d'entrée pour le projet R |
| Projet L (ensemble de données associé) |
Règle de sortie pour le projet E Règle d'entrée pour le projet R |
Mettre à jour une fiche
Lorsque vous mettez à jour une fiche (par exemple, pour modifier sa règle d'exportation restreinte), le partage BigQuery utilise un processus en arrière-plan pour propager ces modifications aux ensembles de données associés. Si votre projet Google Cloud est protégé par un périmètre VPC Service Controls avec des restrictions basées sur les adresses IP, le worker en arrière-plan provenant de l'infrastructure Google peut être bloqué, ce qui empêche la synchronisation de l'ensemble de données associé.
Pour permettre au nœud de calcul en arrière-plan de mettre à jour l'ensemble de données associé, vous devez configurer explicitement vos règles d'entrée ou de sortie pour permettre au compte de service principal ou à l'utilisateur principal exécutant l'appel d'API de contourner les restrictions basées sur l'adresse IP.
Pour modifier la règle d'entrée du périmètre du projet abonné, ajoutez une règle d'entrée qui permet au compte principal appelant d'accéder au service bigquery.googleapis.com depuis n'importe quelle adresse IP source (*) :
ingressFrom:
sources:
- accessLevel: "*"
identities:
- "user:CALLING_USER_EMAIL"
- "serviceAccount:AUTOMATION_SA_EMAIL"
ingressTo:
resources:
- "projects/SUBSCRIBER_PROJECT_NUMBER"
operations:
- serviceName: "bigquery.googleapis.com"
methodSelectors:
- method: "*"
Vous pouvez également modifier la règle de sortie sur le périmètre de l'éditeur. Pour cela, vérifiez que l'identité appelante est explicitement ajoutée à la liste identities dans la règle de sortie dirigée vers le projet de l'abonné :
egressFrom:
identities:
- "user:CALLING_USER_EMAIL"
- "serviceAccount:AUTOMATION_SA_EMAIL"
egressTo:
resources:
- "projects/SUBSCRIBER_PROJECT_NUMBER"
operations:
- serviceName: "bigquery.googleapis.com"
methodSelectors:
- method: "*"
Remplacez les éléments suivants :
CALLING_USER_EMAIL: adresse e-mail de l'utilisateur qui exécute l'appel d'API pour modifier la fiche. Incluez cette identité si un utilisateur humain effectue la modification.AUTOMATION_SA_EMAIL: adresse e-mail du compte de service qui exécute l'appel d'API pour mettre à jour la fiche. Incluez cette identité si un processus ou un script automatisé effectue la mise à jour.SUBSCRIBER_PROJECT_NUMBER: numéro du projet abonné contenant l'ensemble de données associé.
Interroger les tables d'un ensemble de données associé
Dans le schéma suivant, le projet appelant et le projet contenant l'ensemble de données associé se trouvent dans des périmètres de service différents :
Figure 4. Règles de VPC Service Controls permettant d'interroger un ensemble de données associé
Dans la figure 4, les composants suivants sont associés à des libellés :
- L'appelant est un abonné BigQuery Sharing ou tout utilisateur de tâche BigQuery de l'ensemble de données associé.
- Projet R : projet appelant.
- Projet L : héberge l'ensemble de données associé.
- Projet V : héberge l'ensemble de données partagé contenant la table.
En tant qu'abonné au partage BigQuery, lorsque vous interrogez une table dans l'ensemble de données associé, vous devez ajouter les règles d'entrée et de sortie suivantes :
| Projet | Règle |
|---|---|
| Projet R | Règle de sortie pour le projet L |
| Projet L (ensemble de données associé) | Règle d'entrée pour le projet R |
Interroger les vues dans un ensemble de données associé
Cette section décrit les règles VPC Service Controls requises pour interroger une vue dans un ensemble de données associé. Les règles varient selon que la vue et ses tables de base sous-jacentes se trouvent dans le même projet ou dans des projets distincts.
Scénario 1
Dans le schéma suivant, les projets contenant l'ensemble de données associé et les tables de base associées à la vue se trouvent dans des périmètres de service différents. La vue (Projet S) et la table de base associée à la vue (Projet V) se trouvent dans différents projets :
Figure 5. Règles VPC Service Controls permettant d'interroger une vue dans un ensemble de données associé
Dans la figure 5, les composants suivants sont associés à des libellés :
- L'appelant est un abonné BigQuery Sharing ou tout utilisateur de tâche BigQuery de l'ensemble de données associé.
- Projet R : projet appelant.
- Projet L : héberge l'ensemble de données associé.
- Projet S : héberge l'ensemble de données partagé.
- Projet V : héberge l'ensemble de données contenant les tables de base associées à la vue.
En tant qu'abonné au partage BigQuery, lorsque vous interrogez une vue dans un ensemble de données associé, vous devez ajouter les règles d'entrée et de sortie suivantes :
| Projet | Règle |
|---|---|
| Projet R |
Règle de sortie pour le projet L Règle de sortie pour le projet V |
| Projet L (ensemble de données associé) |
Règle d'entrée pour le projet R Règle de sortie pour le projet V |
| Projet V |
Règle de sortie pour le projet L Règle d'entrée pour le projet R |
Scénario 2
Dans la figure suivante, la vue (Projet V) et la table de base associée à cette vue (Projet V) se trouvent dans le même projet :
Figure 6. Règles VPC Service Controls permettant d'interroger une vue dans un ensemble de données associé
Dans la figure 6, les composants suivants sont associés à des libellés :
- L'appelant est un abonné BigQuery Sharing ou tout utilisateur de tâche BigQuery de l'ensemble de données associé.
- Projet R : projet appelant.
- Projet L : héberge l'ensemble de données associé.
- Projet V : héberge la vue et les tables de base associées à cette vue.
En tant qu'abonné au partage BigQuery, lorsque vous interrogez une vue dans un ensemble de données associé, vous devez ajouter les règles d'entrée et de sortie suivantes :
| Projet | Règle |
|---|---|
| Projet R |
Règle de sortie pour le projet L |
| Projet L (ensemble de données associé) |
Règle d'entrée pour le projet R |
Interroger les vues autorisées dans un ensemble de données associé
Dans le diagramme suivant, la vue autorisée et la table de base associée à la vue autorisée (projet V) se trouvent dans le même projet :
Figure 7. Règles VPC Service Controls permettant d'interroger une vue dans un ensemble de données associé
Dans la figure 7, les composants suivants sont associés à des libellés :
- L'appelant est un abonné BigQuery Sharing ou tout utilisateur de tâche BigQuery de l'ensemble de données associé.
- Projet R : projet appelant.
- Projet L : héberge l'ensemble de données associé.
- Projet V : héberge la vue autorisée et les tables de base associées à la vue.
En tant qu'abonné au partage BigQuery, lorsque vous interrogez une vue dans un ensemble de données associé, vous devez ajouter les règles d'entrée et de sortie suivantes :
| Projet | Règle |
|---|---|
| Projet R |
Règle de sortie pour le projet L |
| Projet L (ensemble de données associé) |
Règle d'entrée pour le projet R |
Limites
BigQuery Sharing n'est pas compatible avec les règles basées sur les méthodes. Vous devez autoriser toutes les méthodes pour activer les règles basées sur les méthodes. Exemple :
ingressTo:
operations:
- methodSelectors:
- method: '*'
serviceName: analyticshub.googleapis.com
resources:
- projects/PROJECT_ID
Si les ressources BigQuery sont également protégées par des périmètres de service, vous devez autoriser les règles d'entrée et de sortie pour le service BigQuery. Il n'est pas nécessaire d'autoriser les règles d'entrée et de sortie lorsque vous créez un échange de données. Les règles d'entrée et de sortie pour BigQuery sont semblables à celles pour le partage BigQuery. Exemple :
ingressTo:
operations:
- methodSelectors:
- method: '*'
serviceName: bigquery.googleapis.com
resources:
- projects/PROJECT_ID
Étapes suivantes
- Découvrez comment résoudre les problèmes liés à VPC Service Controls.
- En savoir plus sur les règles d'entrée et de sortie
- Découvrez comment configurer des règles d'entrée et de sortie.
- Découvrez comment créer une fiche.
- En savoir plus sur l'abonnement à une fiche
- En savoir plus sur la journalisation d'audit du partage