Bereitstellung von Anmeldedaten – Übersicht

Im Modus für die Bereitstellung von Anmeldedaten im Lakehouse-Laufzeitkatalog können Sie den Cloud Storage-Zugriff an Abfrage-Engines delegieren und detaillierte IAM-Richtlinien (Identity and Access Management) auf Katalog-, Namespace- und Tabellenebene für Apache Iceberg-Tabellen erzwingen. Anstatt direkte Bucket-Berechtigungen zu gewähren, konfigurieren Sie den Apache Iceberg REST-Katalogendpunkt so, dass er kurzlebige, eingeschränkte Speichertokens für autorisierte Tabellenpfade bereitstellt. Dieser Modus ist auch für die automatische Tabellenverwaltung erforderlich.

Wann sollte die Bereitstellung von Anmeldedaten verwendet werden?

Im Folgenden sind einige gängige Anwendungsfälle aufgeführt:

  • Zugriff auf Tabellenebene ohne Rollen auf Bucket-Ebene erzwingen: Gewähren Sie Analysten und Arbeitslasten Zugriff auf bestimmte Apache Iceberg-Tabellen, verhindern Sie jedoch den direkten Zugriff auf zugrunde liegende Cloud Storage-Buckets oder gleichgeordnete Tabellenverzeichnisse.
  • Access Governance über mehrere Abfrage-Engines hinweg zentralisieren: Wenden Sie konsistente IAM-Richtlinien auf BigQuery, Managed Service for Apache Spark, Open-Source-Apache Spark und Trino an, indem Sie kurzlebige, pfadbezogene Tokens verwenden.
  • Warehouse-Buckets innerhalb eines Dienstperimeters isolieren: Speichern Sie Tabellendaten in Cloud Storage-Buckets, die durch VPC Service Controls geschützt sind, und autorisieren Sie Lese- und Schreibvorgänge im Speicher über ein einziges Dienstkonto für den Katalogendpunkt.

Funktionsweise der Bereitstellung von Anmeldedaten

Wenn Sie den Modus für die Bereitstellung von Anmeldedaten verwenden, werden IAM-Richtlinien durch die Abfolge der Vorgänge erzwungen, bevor auf den Speicher zugegriffen wird. Das folgende Diagramm zeigt, wie Abfrage-Engines eingeschränkte Speicher-Tokens aus dem Lakehouse-Laufzeitkatalog abrufen, um Daten sicher direkt in Cloud Storage zu lesen und zu schreiben:

Abfrage-Engines rufen eingeschränkte Speicher-Tokens aus dem Lakehouse-Laufzeitkatalog ab, um Daten in Cloud Storage zu lesen und zu schreiben.
Workflow für die Bereitstellung von Anmeldedaten, der den Zugriff auf Cloud Storage delegiert.

Die im vorherigen Diagramm dargestellte Abfolge von Vorgängen sieht so aus:

  1. Anfrage: Ein Nutzer sendet eine SQL-Anweisung, z. B. einen Abfrage-, DML- oder DDL-Vorgang, an eine unterstützte Engine, z. B. Spark oder BigQuery.
  2. Metadatensuche: Die Engine sendet eine Anfrage an den Lakehouse-Laufzeitkatalog, um die Tabelle aufzulösen.
  3. Authentifizierung und Richtlinie: Der Lakehouse-Laufzeitkatalog authentifiziert den Nutzer und prüft seine IAM-Berechtigungen für Lakehouse-Ressourcen.
  4. Antwort: Da der Modus für die Bereitstellung von Anmeldedaten aktiviert ist, gibt der Lakehouse-Laufzeitkatalog die Metadaten und ein kurzlebiges Speichertoken (Speicheranmeldedaten mit eingeschränktem Bereich) an die Engine zurück. Das Token ist auf die mit der Tabelle verknüpften Pfade beschränkt und auf die minimal erforderlichen Berechtigungen reduziert (z. B. schreibgeschützter Zugriff für Abfragen, die keine Dateien schreiben müssen).
  5. Zugriff: Die Engine verwendet dieses Token, um die spezifischen autorisierten Dateien direkt aus Cloud Storage zu lesen oder in Cloud Storage zu schreiben.
  6. Compute: Die Engine verarbeitet die Daten oder führt den Vorgang aus und gibt die Ergebnisse zurück.

Wenn die automatische Tabellenverwaltung (gcp.biglake.table-management.enabled) aktiviert ist, werden Hintergrundwartungsaufgaben wie Komprimierung, Snapshot-Ablauf und automatische Speicherbereinigung über das automatisch bereitgestellte Dienstkonto des Katalogs authentifiziert, um sich direkt bei Cloud Storage zu authentifizieren und die zugrunde liegenden Datendateien zu aktualisieren.

Unterstützte Suchmaschinen

Wenn Sie die Bereitstellung von Anmeldedaten mit Abfrage-Engines verwenden möchten, müssen Sie den Apache Iceberg REST-Katalogendpunkt in Ihrem Lakehouse-Laufzeitkatalog im Modus für die Bereitstellung von Anmeldedaten konfigurieren. Die Bereitstellung von Anmeldedaten wird für Apache Hive-Katalogendpunkte nicht unterstützt.

  • Open-Source-Engines: Unterstützte Engines wie Spark und Trino verwenden kurzlebige Speichertokens, die vom Lakehouse-Laufzeitkatalog bereitgestellt werden. Ihre Clientanwendung muss die Unterstützung für die Bereitstellung von Anmeldedaten im X-Iceberg-Access-Delegation-Header angeben.
  • BigQuery: BigQuery verwendet für den Zugriff auf Cloud Storage bereitgestellte Anmeldedaten anstelle von Endnutzer-Anmeldedaten.

Erforderliche Dienstkontoberechtigungen

Wenn der Modus für die Bereitstellung von Anmeldedaten aktiviert ist, müssen die folgenden Dienstkonten die erforderlichen Rollen haben:

  • Automatisch bereitgestelltes Dienstkonto für Katalogendpunkte: Sie müssen diesem Konto die Rolle „Storage-Objekt-Nutzer“ (roles/storage.objectUser) für alle zugehörigen Cloud Storage-Buckets zuweisen. Ohne diesen Zugriff können die bereitgestellten Anmeldedaten nicht auf den Speicher zugreifen oder darin schreiben. Wenn Sie dieGoogle Cloud Console verwenden, wird diese Rolle durch Klicken auf Bucket-Berechtigungen festlegen bestätigt. Für die Google Cloud CLI, Terraform oder die REST API müssen Sie diese Rolle manuell zuweisen.
  • Dienstkonten für Abfrage-Engines: Dienstkonten, die Abfrage-Engine-Jobs ausführen (z. B. Managed Service for Apache Spark oder Dataflow), benötigen die Rolle „BigLake-Bearbeiter“ (roles/biglake.editor), um bereitgestellte Anmeldedaten mit Schreibbereich zu erhalten.

VPC Service Controls mit der Bereitstellung von Anmeldedaten verwenden

Wenn Sie den Apache Iceberg REST-Katalogendpunkt im Modus für die Bereitstellung von Anmeldedaten mit Cloud Storage-Buckets innerhalb eines VPC Service Controls-Dienstperimeters verwenden, können Sie die folgenden Anwendungsfälle unterstützen:

  • Apache Iceberg-Tabellen in geschützten Buckets erstellen und ändern: Führen Sie CREATE TABLE- oder DML-Anweisungen über BigQuery, Managed Service for Apache Spark, Spark oder Trino aus, wenn sich Warehouse-Buckets innerhalb eines Dienstperimeters befinden.
  • Detaillierte Tabellenlesevorgänge innerhalb eines Speicherperimeters delegieren: IAM-Richtlinien auf Tabellenebene mit kurzlebigen, eingeschränkten Speicher-Tokens erzwingen, ohne Endnutzern oder Abfragelaufzeiten direkte IAM-Rollen für Perimeter-geschützte Buckets zu gewähren.

Im Modus für die Bereitstellung von Anmeldedaten authentifizieren sich Abfrage-Engines und Lakehouse bei Cloud Storage mit Anmeldedaten, die für das automatisch bereitgestellte Dienstkonto des Katalogendpunkts (blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.) ausgestellt wurden. Da dieser Dienst-Agent zu einem von Google verwalteten Projekt außerhalb Ihres Dienstperimeters gehört, wertet Cloud Storage Anfragen, die mit seinen Anmeldedaten authentifiziert wurden, als eingehenden Perimeter-Traffic aus, wenn der Perimeter des Bucket-Projekts storage.googleapis.com einschränkt. Diese Bewertung gilt auch, wenn sich der Katalogendpunkt, der Abfragejob und der Bucket im selben Projekt und Dienstperimeter befinden.

Wenn Sie Zugriff gewähren möchten, konfigurieren Sie im Access Context Manager eine Regel für eingehenden Traffic für den Perimeter, der das Bucket-Projekt schützt. Verwenden Sie dazu die folgenden Einstellungen:

  • Quellidentität: serviceAccount:blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.
  • Zielprojekt: Das Bucket-Projekt (projects/BUCKET_PROJECT_NUMBER)
  • Dienst: storage.googleapis.com mit allen Methoden ('*') oder bestimmten unterstützten Dienstmethoden

Im folgenden ingress.yaml-Beispiel wird dem Dienstkonto des Katalogendpunkts Zugriff auf storage.googleapis.com im Bucket-Projekt gewährt:

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

Ersetzen Sie Folgendes:

  • CATALOG_ENDPOINT_SERVICE_ACCOUNT: Die automatisch bereitgestellte E-Mail-Adresse des Dienstkontos für den Katalogendpunkt (blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.). Um diese E-Mail-Adresse abzurufen, beschreiben Sie den Katalogendpunkt:

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

    In diesem Befehl ist CATALOG_ID die ID Ihres Katalogendpunkts und PROJECT_ID die ID des Projekts, das den Katalogendpunkt enthält.

  • BUCKET_PROJECT_NUMBER: die numerische Projektnummer des Projekts, das den Cloud Storage-Bucket enthält.

Wenn eine Anfrage zum Erstellen einer Tabelle oder eine Abfrageanfrage von VPC Service Controls blockiert wird, enthält die Fehlermeldung einen vpcServiceControlsUniqueIdentifier-Wert. Suchen Sie in Cloud-Audit-Logs nach Audit-Logs zu Richtlinienverstößen, indem Sie protoPayload.metadata.vpcServiceControlsUniqueId mit dieser Kennung abgleichen, und prüfen Sie ingressViolations auf das Hauptkonto blirc-.... Weitere Informationen finden Sie unter VPC Service Controls-Fehler aus Audit-Logs abrufen.

Nächste Schritte