VPC Service Controls mit föderierten Katalogendpunkten verwenden

Im Lakehouse-Laufzeitkatalog können Sie mit VPC Service Controls-Perimeterregeln für föderierte Katalogendpunkte externe Apache Iceberg-Tabellen in BigQuery abfragen und gleichzeitig die Daten-Exfiltration verhindern. Wenn sich IhreGoogle Cloud -Projekte oder Cloud Storage-Buckets innerhalb eines Dienstperimeters befinden, können Sie Regeln für ausgehenden Traffic für Amazon S3 und Microsoft Azure Data Lake Storage (ADLS) Gen2 oder Regeln für eingehenden Traffic für Cloud Storage konfigurieren. Diese Regeln autorisieren die Metadatensynchronisierung und Abfragen für Tabellen, die in AWS Glue Data Catalog, Databricks Unity Catalog, Snowflake Horizon Catalog und Workday Data Lake registriert sind.

Wenn sich Ihre Projekte nicht innerhalb eines Dienstperimeters befinden, funktionieren föderierte Katalogendpunkte ohne VPC Service Controls-Konfiguration. Informationen zu cloudübergreifenden Verbindungen zu SAP Business Data Cloud (SAP BDC) finden Sie unter VPC Service Controls-Konfiguration für SAP BDC. Informationen zum Schützen von Buckets, auf die über den Apache Iceberg REST-Katalogendpunkt im Modus für die Bereitstellung von Anmeldedaten zugegriffen wird, finden Sie unter VPC Service Controls mit der Bereitstellung von Anmeldedaten verwenden.

Hinweis

  1. Richten Sie einen föderierten Katalogendpunkt für AWS Glue Data Catalog, Databricks Unity Catalog, Snowflake Horizon Catalog oder Workday Data Lake ein.

  2. Erstellen Sie einen oder mehrere Dienstperimeter für Ihre Projekte, je nachdem, wo Ihre Tabellendateien gespeichert sind:

    • Externer Cloud-Speicher (Amazon S3 oder ADLS Gen2): Schützen Sie Ihr Projekt mit dem Endpunkt für den föderierten Katalog mit einem Perimeter, der biglake.googleapis.com und bigquery.googleapis.com einschränkt. Informationen zur erforderlichen Regel für ausgehenden Traffic finden Sie unter Regel für ausgehenden Traffic für externen Cloud-Speicher hinzufügen.
    • Cloud Storage: Schützen Sie Ihr Cloud Storage-Bucket-Projekt mit einem Perimeter, der storage.googleapis.com einschränkt. Das Bucket-Projekt und das Projekt mit dem Endpunkt des föderierten Katalogs können sich entweder in einem gemeinsamen Perimeter oder in separaten Perimetern befinden. Informationen zur erforderlichen Regel für eingehenden Traffic finden Sie unter Regel für eingehenden Traffic für Cloud Storage-Buckets in einem Dienstperimeter hinzufügen.

  3. Wenn Nutzer oder Dienstkonten außerhalb des Perimeters den föderierten Katalogendpunkt abfragen, fügen Sie eine Regel für eingehenden Traffic hinzu, die ihnen Zugriff auf den Perimeter des Katalogendpunktprojekts gewährt.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihre Organisation zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Konfigurieren von Dienstperimetern benötigen:

  • Dienstperimeter und Richtlinien für ein- oder ausgehenden Traffic konfigurieren: Access Context Manager Editor (roles/accesscontextmanager.policyEditor)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Anwendungsfälle und erforderliche Perimeterregeln

Die von Ihnen konfigurierten Perimeterregeln hängen davon ab, wo sich Ihre Tabellendateien befinden und wo Ihre Abfrageaufrufer ausgeführt werden:

Anwendungsfall Erforderliche Perimeterregel Konfigurationsschritte
Cloudübergreifende Tabellen in Amazon S3 oder ADLS Gen2 abfragen: Apache Iceberg-Tabellen in s3://-Buckets oder abfss://-Containern über einen föderierten Katalogendpunkt in einem geschützten BigQuery-Projekt abfragen und gleichzeitig nicht autorisierten ausgehenden Traffic blockieren. Fügen Sie im Perimeter des Katalogendpunktprojekts eine Regel für ausgehenden Traffic hinzu, die sowohl dem Dienstkonto blirc-... des Katalogendpunkts als auch Ihren Abfragehauptkonten das Lesen der genehmigten externen Buckets oder Container ermöglicht. Suchen Sie das Dienstkonto des Katalogendpunkts und fügen Sie eine Regel für ausgehenden Traffic für externen Cloud-Speicher hinzu.
Auf externe Katalogtabellen in geschützten Cloud Storage-Buckets zugreifen: Fragen Sie Databricks Unity Catalog- oder Snowflake Horizon Catalog-Tabellen ab, die in einem gs://-Bucket innerhalb eines Perimeters gespeichert sind, der storage.googleapis.com einschränkt (auch im selben Projekt und Perimeter wie der Endpunkt des föderierten Katalogs). Fügen Sie dem Perimeter des Cloud Storage-Bucket-Projekts eine Regel für eingehenden Traffic hinzu, die dem Dienstkonto Google Cloud des Remote-Katalogs den Zugriff auf storage.googleapis.com ermöglicht. Regel für eingehenden Traffic für Cloud Storage-Buckets in einem Dienstperimeter hinzufügen
Abfragen von Aufrufern außerhalb des Perimeters des Katalogendpunkts zulassen: BigQuery-Jobs im Projekt des Katalogendpunkts über Analystenkonten, BI-Tools oder Dienstkonten für Arbeitslasten außerhalb des Perimeters ausführen. Fügen Sie dem Perimeter des Katalogendpunktprojekts eine Regel für eingehenden Traffic hinzu, die die externen Aufrufer für bigquery.googleapis.com und biglake.googleapis.com zulässt, zusätzlich zur Speicherregel für Ihren Tabellenstandort. Konfigurieren Sie den eingehenden Traffic des Aufrufers mithilfe der Referenz für Regeln für eingehenden Traffic und folgen Sie dann dem Speicherverfahren für den Speicherort Ihrer Tabelle.

So wertet VPC Service Controls den Traffic von föderierten Katalogendpunkten aus

Ein föderierter Katalogendpunkt führt zwei unterschiedliche Vorgänge aus, die Daten aus dem zugrunde liegenden Speicher lesen: Metadatensynchronisierung und BigQuery-Abfragen. Wie VPC Service Controls diese Vorgänge auswertet, hängt davon ab, wo Ihre Tabellendateien gespeichert sind:

  • Externer Cloud-Speicher (Amazon S3 oder Azure Data Lake Storage Gen2): VPC Service Controls wertet den ausgehenden Traffic vom Dienstperimeter des Katalogendpunktprojekts anhand der Aufruferidentität inGoogle Cloud und des externen Ziel-Buckets oder ‑Containers aus:

    Vorgang Identität bewertet Ressource bewertet
    Metadatensynchronisierung Das automatisch bereitgestellte Lakehouse-Dienstkonto des Katalogendpunkts (blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.iam.gserviceaccount.com) Der externe Bucket oder Container, der die Apache Iceberg-Metadaten der Tabelle enthält
    Abfrage Das Nutzer- oder Dienstkonto, das den BigQuery-Job ausführt Die externen Buckets oder Container, die die Metadaten und Datendateien der Tabelle enthalten

    Für Tabellen, die in Amazon S3 oder ADLS Gen2 gespeichert sind, muss die Regel für ausgehenden Traffic Ihres Perimeters Folgendes enthalten:

    • Identitäten: sowohl das Dienstkonto des Katalogendpunkts als auch Ihre Abfragehauptkonten.
    • Externe Ressourcen: alle Buckets oder Container, die Ihre Tabellen für Metadaten und Datendateien verwenden.
    • Vorgänge: sowohl bigquery.googleapis.com (mit der Berechtigung externalResource.read) als auch biglake.googleapis.com (mit allen Methoden, '*').

  • Cloud Storage (externe Speicherorte von Databricks Unity Catalog oder Snowflake Horizon Catalog in Google Cloud): Sowohl bei der Metadatensynchronisierung als auch bei BigQuery-Abfragen lesen BigQuery und Lakehouse aus Cloud Storage. Dabei werden die vom Remote-Katalog bereitgestellten eingeschränkten Anmeldedaten verwendet, nicht das Dienstkonto blirc-... des Katalogendpunkts. Wenn sich das Cloud Storage-Bucket-Projekt innerhalb eines Dienstperimeters befindet, der storage.googleapis.com einschränkt, wertet storage.googleapis.com das Dienstkonto des Remote-Katalogs Google Cloud als externe Identität aus, die versucht, in den Perimeter einzudringen. Diese Bewertung gilt auch, wenn sich der Bucket im selben Projekt und Dienstperimeter wie der föderierte Katalogendpunkt befindet. Sie müssen dem Dienstperimeter des Bucket-Projekts eine Regel für eingehenden Traffic hinzufügen, die dem Dienstkonto des Remote-KatalogsGoogle Cloud Zugriff auf storage.googleapis.com gewährt.

VPC Service Controls wertet nur Speicherlesevorgänge aus, die von BigQuery und Lakehouse (biglake.googleapis.com) ausgeführt werden. Aufrufe, die Lakehouse an den API-Endpunkt des Remote-Katalogs richtet (z. B. Auflisten von Namespaces und Tabellen), werden nicht ausgewertet. Externe Abfrage-Engines, die Ihren Speicher direkt lesen, werden nicht gesteuert.

Formate für externe Ressourcen

Geben Sie externe Ressourcen in Regeln für ausgehenden Traffic als genauen Bucket- oder Container-URI an. Objektpfade und Platzhalter werden nicht unterstützt. Bucket-, Container- und Speicherkontonamen müssen in Kleinbuchstaben geschrieben werden. Regeln, die Großbuchstaben in diesen Namen enthalten, werden beim Speichern der Regel abgelehnt. URIs für Azure Data Lake Storage Gen2 (abfss://) und Azure Blob Storage (azure://) sind in VPC Service Controls-Regeln für ausgehenden Traffic nicht austauschbar. Für föderierte Katalogendpunkte müssen Sie das Format abfss:// angeben.

In der folgenden Tabelle sind die unterstützten URI-Formate für externe Ressourcen für föderierte Katalogendpunkte aufgeführt:

Speicherdienst Format Beispiel
Amazon S3 s3://BUCKET_NAME s3://my-iceberg-warehouse
Azure Data Lake Storage Gen2 abfss://CONTAINER@STORAGE_ACCOUNT.dfs.core.windows.net abfss://unity-catalog-storage@mystorageaccount.dfs.core.windows.net

Dienstkonto des Katalogendpunkts ermitteln

Lakehouse stellt für jeden föderierten Katalogendpunkt ein dediziertes Dienstkonto bereit, wenn Sie den Katalogendpunkt erstellen. Für Tabellen in Cloud Storage fahren Sie mit Regel für eingehenden Traffic für Cloud Storage-Buckets in einem Dienstperimeter hinzufügen fort. Wenn Ihre Tabellen in Amazon S3 oder ADLS Gen2 gespeichert sind, rufen Sie diese Dienstkonto-E-Mail-Adresse für Ihre Regel für ausgehenden Traffic ab:

gcloud biglake iceberg catalogs describe CATALOG_ID \
    --project=PROJECT_ID \
    --format='value(biglake-service-account)'

Ersetzen Sie Folgendes:

  • CATALOG_ID: die ID des Endpunkts Ihres föderierten Katalogs.
  • PROJECT_ID: die ID des Google Cloud-Projekts, das den Endpunkt des föderierten Katalogs enthält.

Der Befehl gibt eine E-Mail-Adresse im folgenden Format zurück:

blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.iam.gserviceaccount.com

Regel für ausgehenden Traffic für externen Cloud-Speicher hinzufügen

Wenn Tabellen, auf die über den Endpunkt Ihres föderierten Katalogs zugegriffen wird, in Amazon S3 oder ADLS Gen2 gespeichert sind, fügen Sie dem Dienstperimeter, der Ihr Katalogendpunktprojekt schützt, eine Regel für ausgehenden Traffic hinzu.

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite VPC Service Controls.

    Zu „VPC Service Controls“

  2. Wählen Sie Ihre Organisation und Zugriffsrichtlinie aus und klicken Sie dann auf den Namen des Dienstperimeters, der Ihr Katalogendpunktprojekt enthält.

  3. Klicken Sie auf Bearbeiten und dann im Bereich Richtlinie für ausgehenden Traffic auf Regel für ausgehenden Traffic hinzufügen.

  4. Wählen Sie im Abschnitt Von unter Identitäten die Option Identitäten und Gruppen auswählen aus, klicken Sie auf Identitäten hinzufügen und fügen Sie das Dienstkonto des Katalogendpunkts und die Nutzer oder Dienstkonten hinzu, die Abfragen ausführen.

  5. Im Abschnitt An:

    1. Wählen Sie Externe Ressourcen aus, klicken Sie auf Ressourcen hinzufügen, geben Sie jeden s3://-Bucket oder abfss://-Container ein, der von Ihren Tabellen verwendet wird, und klicken Sie auf Externe Ressourcen hinzufügen.
    2. Konfigurieren Sie unter Vorgänge oder IAM-Rollen die folgenden Dienste in der Tabelle API-Vorgänge:
      • BigQuery API (bigquery.googleapis.com): Wenn Sie den Standardeintrag für alle Methoden (*) auf Lesezugriff beschränken möchten, öffnen Sie das Aktionsmenü für bigquery.googleapis.com und klicken Sie auf Bearbeiten. Wählen Sie Methoden auswählen aus, wählen Sie die Berechtigung externalResource.read aus und klicken Sie auf Ausgewählte Methoden hinzufügen.
      • BigLake API (biglake.googleapis.com): Klicken Sie auf Vorgänge hinzufügen, wählen Sie BigLake API (biglake.googleapis.com) aus, wählen Sie Alle Methoden aus und klicken Sie auf Alle Methoden hinzufügen.

  6. Klicken Sie auf Speichern.

gcloud-CLI

  1. Erstellen Sie eine Datei mit dem Namen egress.yaml, in der das Dienstkonto des Katalogendpunkts, die Abfrage-Hauptkonten und alle externen Buckets oder Container angegeben sind, die von Ihren Tabellen verwendet werden. Das vollständige Schema finden Sie in der Referenz zu Regeln für ausgehenden Traffic.

    - egressFrom:
    identities:
    - serviceAccount:CATALOG_ENDPOINT_SERVICE_ACCOUNT
    - user:QUERY_USER_EMAIL
  egressTo:
    externalResources:
    - s3://S3_BUCKET_NAME
    - abfss://ADLS_CONTAINER@STORAGE_ACCOUNT.dfs.core.windows.net
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - permission: externalResource.read
    - serviceName: biglake.googleapis.com
      methodSelectors:
      - method: '*'

    Ersetzen Sie Folgendes:

    • CATALOG_ENDPOINT_SERVICE_ACCOUNT: die E-Mail-Adresse des Dienstkontos des Katalogendpunkts, die Sie zuvor abgerufen haben.
    • QUERY_USER_EMAIL: die E-Mail-Adresse eines Nutzer- oder Dienstkontos, das Abfragen über den Endpunkt des föderierten Katalogs ausführt. Verwenden Sie für ein Dienstkonto das Präfix serviceAccount: anstelle von user:. Alternativ können Sie identities durch identityType: ANY_IDENTITY ersetzen, um alle Hauptkonten im Perimeter zuzulassen.
    • S3_BUCKET_NAME, ADLS_CONTAINER und STORAGE_ACCOUNT: die externen Speicherorte, an denen Ihre Tabellenmetadaten und Datendateien gespeichert sind. Fügen Sie nur die Einträge ein, die für Ihren Speicheranbieter gelten.

  2. Suchen Sie die numerische ID der Zugriffsrichtlinie Ihrer Organisation:

    gcloud access-context-manager policies list \
    --organization=ORGANIZATION_ID \
    --format='value(name)'

    Ersetzen Sie ORGANIZATION_ID durch Ihre numerische Organisations-ID.

  3. Wenden Sie die Regel für ausgehenden Traffic auf Ihren Dienstperimeter an:

    gcloud access-context-manager perimeters update PERIMETER_NAME \
    --policy=POLICY_ID \
    --set-egress-policies=egress.yaml

    Ersetzen Sie Folgendes:

    • PERIMETER_NAME: der Name Ihres Dienstperimeters.
    • POLICY_ID: die numerische ID Ihrer Zugriffsrichtlinie.

    Wenn Sie die Regel testen möchten, bevor Sie sie erzwingen, wenden Sie sie mit gcloud access-context-manager perimeters dry-run update auf eine Probelaufkonfiguration an und erzwingen Sie sie nach der Validierung mit gcloud access-context-manager perimeters dry-run enforce.

  4. Die Regel muss aktiviert sein:

    gcloud access-context-manager perimeters describe PERIMETER_NAME \
    --policy=POLICY_ID \
    --format='yaml(status.egressPolicies)'

Regel für eingehenden Traffic für Cloud Storage-Buckets in einem Dienstperimeter hinzufügen

Wenn Tabellen in einem Remote-Katalog (z. B. Databricks Unity Catalog oder Snowflake Horizon Catalog) in einem Cloud Storage-Bucket gespeichert sind, der durch einen Perimeter geschützt ist, der storage.googleapis.com einschränkt, fügen Sie dem Dienstperimeter des Bucket-Projekts eine Regel für eingehenden Traffic hinzu. Da sich BigQuery und Lakehouse bei Cloud Storage mit dem Dienstkonto Google Cloud des Remote-Katalogs (nicht mit dem Dienstkontoblirc-...) authentifizieren, ist diese Regel auch dann erforderlich, wenn sich der Bucket im selben Projekt und Perimeter wie der Endpunkt des föderierten Katalogs befindet.

Console

  1. Wechseln Sie in der Google Cloud Console zur Seite VPC Service Controls.

    Zu „VPC Service Controls“

  2. Wählen Sie Ihre Organisation und Zugriffsrichtlinie aus und klicken Sie dann auf den Namen des Dienstperimeters, der das Projekt mit Ihrem Cloud Storage-Bucket schützt.

  3. Klicken Sie auf Bearbeiten und dann im Bereich Richtlinie für eingehenden Traffic auf Regel für eingehenden Traffic hinzufügen.

  4. Im Abschnitt Von:

    1. Wählen Sie unter Identitäten die Option Identitäten und Gruppen auswählen aus, klicken Sie auf Identitäten hinzufügen und fügen Sie das Dienstkonto Google Cloud hinzu, das vom Remote-Katalog für Ihren Cloud Storage-Bucket bereitgestellt wurde.
    2. Wählen Sie unter Quellen die Option Alle Quellen aus oder wählen Sie Quellen auswählen, um eine Zugriffsebene anzugeben.

  5. Im Abschnitt An:

    1. Wählen Sie unter Ressourcen die Option Ressourcen auswählen aus. Klicken Sie auf dem Tab Projekte auf Projekte hinzufügen, wählen Sie das Projekt aus, das Ihren Cloud Storage-Bucket enthält, und klicken Sie auf Ausgewählte Projekte hinzufügen.
    2. Wählen Sie unter Vorgänge oder IAM-Rollen die Option Vorgänge auswählen aus, klicken Sie auf Vorgänge hinzufügen, wählen Sie Cloud Storage API (storage.googleapis.com) aus, wählen Sie Alle Methoden aus und klicken Sie auf Alle Methoden hinzufügen. Alternativ können Sie Methoden auswählen, um bestimmte unterstützte Dienstmethoden (z. B. google.storage.objects.get, google.storage.objects.list und google.storage.buckets.get) auszuwählen, und dann auf Ausgewählte Methoden hinzufügen klicken.

  6. Klicken Sie auf Speichern.

gcloud-CLI

  1. Erstellen Sie eine Datei mit dem Namen ingress.yaml, die dem DienstkontoGoogle Cloud des Remote-Katalogs den Zugriff auf storage.googleapis.com im Projekt des Buckets ermöglicht. Das vollständige Schema finden Sie in der Referenz zu Regeln für eingehenden Traffic.

    - ingressFrom:
    identities:
    - serviceAccount:REMOTE_CATALOG_GCS_SERVICE_ACCOUNT
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: '*'
    resources:
    - projects/BUCKET_PROJECT_NUMBER

    Ersetzen Sie Folgendes:

    • REMOTE_CATALOG_GCS_SERVICE_ACCOUNT: die E-Mail-Adresse desGoogle Cloud -Dienstkontos, die vom Remote-Katalog für den Zugriff auf Ihren Cloud Storage-Bucket bereitgestellt wird (z. B. von DESCRIBE STORAGE CREDENTIAL im Databricks Unity Catalog oder DESC EXTERNAL VOLUME im Snowflake Horizon Catalog).
    • BUCKET_PROJECT_NUMBER: die numerische Projektnummer des Projekts, das den Cloud Storage-Bucket enthält.

  2. Suchen Sie die numerische ID der Zugriffsrichtlinie Ihrer Organisation:

    gcloud access-context-manager policies list \
    --organization=ORGANIZATION_ID \
    --format='value(name)'

    Ersetzen Sie ORGANIZATION_ID durch Ihre numerische Organisations-ID.

  3. Wenden Sie die Regel für eingehenden Traffic auf den Dienstperimeter an, der das Bucket-Projekt schützt:

    gcloud access-context-manager perimeters update BUCKET_PERIMETER_NAME \
    --policy=POLICY_ID \
    --set-ingress-policies=ingress.yaml

    Ersetzen Sie Folgendes:

    • BUCKET_PERIMETER_NAME: der Name des Dienstperimeters, der das Bucket-Projekt schützt.
    • POLICY_ID: die numerische ID Ihrer Zugriffsrichtlinie.

    Wenn Sie die Regel testen möchten, bevor Sie sie erzwingen, wenden Sie sie mit gcloud access-context-manager perimeters dry-run update auf eine Probelaufkonfiguration an und erzwingen Sie sie nach der Validierung mit gcloud access-context-manager perimeters dry-run enforce.

  4. Die Regel muss aktiviert sein:

    gcloud access-context-manager perimeters describe BUCKET_PERIMETER_NAME \
    --policy=POLICY_ID \
    --format='yaml(status.ingressPolicies)'

Konfiguration prüfen

Es kann bis zu 30 Minuten dauern, bis Aktualisierungen der Dienstperimeterrichtlinie übernommen werden. Nachdem die Regel in Kraft getreten ist, prüfen Sie, ob die Metadatensynchronisierung und die BigQuery-Abfragen ohne Ablehnungen durch VPC Service Controls abgeschlossen werden:

  1. Warten Sie, bis der nächste geplante Metadatensynchronisierungszyklus abgeschlossen ist, und prüfen Sie dann die Audit-Logs zu Richtlinienverstößen in Cloud-Audit-Logs, um zu bestätigen, dass keine VPC Service Controls-Verstöße auftreten. Die Synchronisierung wird automatisch nach dem Aktualisierungszeitplan ausgeführt und kann nicht manuell ausgelöst werden.

    Wählen Sie im Log-Explorer das geschützte Projekt aus – Ihr Katalogendpunktprojekt für externen Cloud-Speicher oder Ihr Cloud Storage-Bucket-Projekt für Cloud Storage-Tabellen. Weitere Informationen finden Sie unter VPC Service Controls-Fehler aus Audit-Logs abrufen. Führen Sie die folgende Abfrage aus:

    log_id("cloudaudit.googleapis.com/policy")
protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"

    Wenn nach der Weitergabe Ihrer Regel Verstoß-Einträge angezeigt werden, prüfen Sie die Felder egressViolations.targetResource, ingressViolations.targetResource und authenticationInfo.principalEmail im Logeintrag, um zu bestätigen, dass sie mit den Ressourcen und Identitäten in Ihrer Regel übereinstimmen. Wenn neue Tabellen nicht synchronisiert werden und keine VpcServiceControlAuditMetadata-Einträge angezeigt werden, prüfen Sie die Berechtigungen und Anmeldedaten für den Remote-Katalog. Weitere Informationen finden Sie unter Fehlerbehebung beim cloudübergreifenden Datenzugriff.

  2. Führen Sie eine Testabfrage für eine Tabelle in BigQuery mit der vierteiligen P.C.N.T-Namenskonvention (Project.Catalog.Namespace.Table) aus:

    SELECT COUNT(*)
FROM `PROJECT_ID.CATALOG_ID.NAMESPACE.TABLE_NAME`;

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die ID des Google Cloud-Projekts, das den Endpunkt des föderierten Katalogs enthält.
    • CATALOG_ID: die ID des Endpunkts Ihres föderierten Katalogs.
    • NAMESPACE: der Namespace im Endpunkt des föderierten Katalogs.
    • TABLE_NAME: der Name einer Tabelle im Namespace.

    Wenn eine Abfrage von VPC Service Controls blockiert wird, enthält die Fehlermeldung einen vpcServiceControlsUniqueIdentifier-Wert. Filtern Sie im Log-Explorer die Audit-Logs zu abgelehnten Richtlinien, indem Sie protoPayload.metadata.vpcServiceControlsUniqueId mit dieser Kennung abgleichen:

    log_id("cloudaudit.googleapis.com/policy")
protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="UNIQUE_IDENTIFIER"

    Ersetzen Sie UNIQUE_IDENTIFIER durch den Wert vpcServiceControlsUniqueIdentifier aus der Fehlermeldung.

Nächste Schritte