Panoramica della distribuzione delle credenziali

La distribuzione delle credenziali per il 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 utilizzando la console Google Cloud o Google Cloud CLI. La distribuzione delle credenziali è necessaria anche per abilitare la gestione automatica delle tabelle per le attività di manutenzione in background, come la compattazione, la scadenza degli snapshot e la garbage collection.

Come funziona la distribuzione delle credenziali

Quando utilizzi la distribuzione delle credenziali, la sequenza delle operazioni cambia leggermente per applicare le policy prima dell'accesso allo spazio di archiviazione. Il seguente diagramma illustra come i motori di query ottengono token di archiviazione con scope ridotto dal catalogo per leggere e scrivere in modo sicuro i dati 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 come Apache 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 autentica l'utente e controlla le sue autorizzazioni IAM sulle risorse Lakehouse.
  4. Risposta: poiché la distribuzione delle credenziali è abilitata, il catalogo restituisce al motore i metadati e un token di archiviazione di breve durata (credenziali di archiviazione con ambito ridotto). L'ambito del token è limitato ai percorsi associati alla tabella e 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 il 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 modo che supporti la 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. 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 dei account di servizio richieste

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

  • Service account del catalogo di runtime Lakehouse 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 console Google Cloud , facendo clic su Imposta autorizzazioni bucket verifichi questo ruolo. Per gcloud CLI, Terraform o l'API, 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, Managed Service for Apache Spark o Dataflow) richiedono il ruolo BigLake Editor (roles/biglake.editor) per ottenere credenziali vendute con ambito di scrittura.

Passaggi successivi