Panoramica della distribuzione delle credenziali

La modalità di distribuzione delle credenziali nel catalogo di runtime di Lakehouse ti consente di delegare l'accesso a Cloud Storage ai motori di query e di applicare policy di Identity and Access Management (IAM) granulari a livello di catalogo, spazio dei nomi e tabella per le tabelle Apache Iceberg. Anziché concedere autorizzazioni dirette per i bucket, configura l'endpoint del catalogo REST Apache Iceberg per vendere token di archiviazione con ambito ridotto e di breve durata per i percorsi delle tabelle autorizzati. Questa modalità è necessaria anche per la gestione automatica delle tabelle.

Quando utilizzare la distribuzione delle credenziali

Ecco alcuni casi d'uso comuni:

  • Applica l'accesso a livello di tabella senza ruoli a livello di bucket: concedi ad analisti e workload l'accesso a tabelle Apache Iceberg specifiche, impedendo al contempo l'accesso diretto ai bucket Cloud Storage sottostanti o alle directory delle tabelle di pari livello.
  • Centralizza la governance degli accessi su più motori di query: applica policy IAM coerenti su BigQuery, Managed Service for Apache Spark, Apache Spark open source e Trino utilizzando token di breve durata con ambito di percorso.
  • Isola i bucket del warehouse all'interno di un perimetro di servizio: archivia i dati delle tabelle in bucket Cloud Storage protetti dai Controlli di servizio VPC, autorizzando al contempo le letture e le scritture dello spazio di archiviazione tramite un singolo account di servizio dell'endpoint del catalogo.

Come funziona la distribuzione delle credenziali

Quando utilizzi la modalità di distribuzione delle credenziali, la sequenza di operazioni applica le policy IAM prima di accedere allo spazio di archiviazione. Il seguente diagramma illustra in che modo i motori di query ottengono token di archiviazione con scope ridotto dal catalogo di runtime di Lakehouse per leggere e scrivere dati in modo sicuro direttamente in Cloud Storage:

I motori di query ottengono token di archiviazione con ambito ridotto dal catalogo di runtime di Lakehouse per leggere e scrivere dati in Cloud Storage.
Flusso di lavoro di distribuzione delle credenziali che delega l'accesso a Cloud Storage.

La sequenza di operazioni mostrata nel diagramma precedente è la seguente:

  1. Richiesta: un utente invia un'istruzione SQL, ad esempio un'operazione di query, DML o DDL, a un motore supportato, ad esempio Spark o BigQuery.
  2. Ricerca dei metadati: il motore invia una richiesta al catalogo di runtime Lakehouse per risolvere la tabella.
  3. Autenticazione e policy: il catalogo di runtime di Lakehouse autentica l'utente e controlla le sue autorizzazioni IAM sulle risorse Lakehouse.
  4. Risposta: poiché la modalità di distribuzione delle credenziali è abilitata, il catalogo di runtime di Lakehouse restituisce al motore i metadati e un token di archiviazione di breve durata (credenziali di archiviazione con ambito ridotto). Il token ha come ambito i percorsi associati alla tabella e un ambito ridotto alle autorizzazioni minime richieste (ad esempio, accesso di sola lettura per le query che non devono scrivere file).
  5. Accesso: il motore utilizza questo token per leggere o scrivere i file autorizzati specifici direttamente da Cloud Storage.
  6. Calcolo: il motore elabora i dati o esegue l'operazione e restituisce i risultati.

Quando è abilitata la gestione automatica delle tabelle (gcp.biglake.table-management.enabled), le attività di manutenzione in background come la compattazione, la scadenza degli snapshot e la garbage collection utilizzano l'account di servizio con provisioning automatico del catalogo per autenticarsi direttamente in Cloud Storage e aggiornare i file di dati sottostanti.

Motori supportati

Per utilizzare la distribuzione delle credenziali con i motori di query, devi configurare l'endpoint del catalogo REST Apache Iceberg nel catalogo di runtime Lakehouse in modalità di distribuzione delle credenziali. La distribuzione delle credenziali non è supportata per gli endpoint del catalogo Apache Hive.

  • Motori open source: i motori supportati, come Spark e Trino, utilizzano token di archiviazione di breve durata forniti dal catalogo di runtime Lakehouse. L'applicazione client deve specificare il supporto per la distribuzione delle credenziali nell'intestazione X-Iceberg-Access-Delegation.
  • BigQuery: BigQuery utilizza le credenziali vendute per l'accesso a Cloud Storage anziché le credenziali dell'utente finale.

Autorizzazioni del account di servizio richieste

Quando la modalità di distribuzione delle credenziali è abilitata, assicurati che i seguenti service account dispongano dei ruoli necessari:

  • Service account endpoint del catalogo con provisioning automatico: devi concedere il ruolo Storage Object User (roles/storage.objectUser) a questo account su tutti i bucket Cloud Storage associati. Senza questo accesso, le credenziali vendute non possono leggere o scrivere nello spazio di archiviazione. Se utilizzi la consoleGoogle Cloud , fai clic su Imposta autorizzazioni bucket per verificare questo ruolo. Per Google Cloud CLI, Terraform o l'API REST, devi concedere questo ruolo manualmente.
  • Service account del motore di query: i service account che eseguono job del motore di query (come Managed Service for Apache Spark o Dataflow) richiedono il ruolo BigLake Editor (roles/biglake.editor) per ottenere credenziali vendute con ambito di scrittura.

Utilizza i Controlli di servizio VPC con la distribuzione delle credenziali

Quando utilizzi l'endpoint del catalogo REST di Apache Iceberg in modalità di distribuzione delle credenziali con i bucket Cloud Storage all'interno di un perimetro di servizio Controlli di servizio VPC, puoi supportare i seguenti casi d'uso:

  • Crea e modifica tabelle Apache Iceberg in bucket protetti: esegui istruzioni CREATE TABLE o DML da BigQuery, Managed Service for Apache Spark, Spark o Trino quando i bucket del data warehouse si trovano all'interno di un perimetro di servizio.
  • Delega le letture granulari delle tabelle all'interno di un perimetro di archiviazione: applica policy IAM a livello di tabella utilizzando token di archiviazione con ambito ridotto e di breve durata senza concedere agli utenti finali o ai runtime delle query ruoli IAM diretti sui bucket protetti dal perimetro.

In modalità di distribuzione delle credenziali, i motori di query e Lakehouse si autenticano in Cloud Storage utilizzando le credenziali emesse per il account di servizio con provisioning automatico dell'endpoint del catalogo (blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.). Poiché questo agente di servizio appartiene a un progetto gestito da Google al di fuori del perimetro di servizio, Cloud Storage valuta le richieste autenticate con le sue credenziali come traffico in entrata nel perimetro ogni volta che il perimetro del progetto del bucket limita storage.googleapis.com. Questa valutazione si applica anche quando l'endpoint del catalogo, il job di query e il bucket si trovano nello stesso progetto e nello stesso perimetro di servizio.

Per consentire l'accesso, configura una regola in entrata in Gestore contesto accesso sul perimetro che protegge il progetto del bucket con le seguenti impostazioni:

  • Identità di origine: serviceAccount:blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.
  • Progetto di destinazione: il progetto del bucket (projects/BUCKET_PROJECT_NUMBER)
  • Servizio: storage.googleapis.com con tutti i metodi ('*') o con metodi di servizio supportati specifici

L'esempio ingress.yaml seguente consente al service account dell'endpoint del catalogo di accedere a storage.googleapis.com nel progetto del bucket:

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

Sostituisci quanto segue:

  • CATALOG_ENDPOINT_SERVICE_ACCOUNT: l'indirizzo email del account di servizio con provisioning automatico dell'endpoint del catalogo (blirc-PROJECT_NUMBER-ID@gcp-sa-biglakerestcatalog.). Per recuperare questo indirizzo email, descrivi l'endpoint del catalogo:

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

    In questo comando, CATALOG_ID è l'ID dell'endpoint del catalogo e PROJECT_ID è l'ID del progetto che contiene l'endpoint del catalogo.

  • BUCKET_PROJECT_NUMBER: il numero di progetto numerico del progetto che contiene il bucket Cloud Storage.

Se una richiesta di creazione o query di una tabella viene bloccata dai Controlli di servizio VPC, il messaggio di errore include un valore vpcServiceControlsUniqueIdentifier. Cerca gli audit log di policy negata in Cloud Audit Logs abbinando protoPayload.metadata.vpcServiceControlsUniqueId a quell'identificatore e controlla ingressViolations per l'entità blirc-.... Per saperne di più, consulta Recupera gli errori dei Controlli di servizio VPC dagli audit log.

Passaggi successivi