In che modo Databricks applica l'isolamento degli utenti?

Questa pagina illustra in che modo Azure Databricks usa Lakeguard per applicare l'isolamento degli utenti negli ambienti di calcolo condivisi e il controllo di accesso con granularità fine in calcolo dedicato.

Che cos'è Lakeguard?

Lakeguard è un set di tecnologie in Databricks che applicano l'isolamento del codice e il filtro dei dati in modo che più utenti possano condividere la stessa risorsa di calcolo in modo sicuro e conveniente e accedere ai dati con controlli di accesso con granularità fine sul posto sul calcolo che offre l'accesso con privilegi ai computer.

Come funziona Lakeguard?

Negli ambienti di calcolo condivisi, ad esempio calcolo classico standard, calcolo serverless e sql warehouse, Lakeguard isola il codice utente dal motore Spark e da altri utenti. Questa progettazione consente a molti utenti di condividere le stesse risorse di calcolo mantenendo limiti rigorosi tra utenti, driver Spark ed executor. Poiché questo isolamento è stato applicato, l'ambiente di calcolo standard può applicare in modo nativo controlli di accesso con granularità fine, ad esempio filtri di riga e maschere di colonna.

Il calcolo dedicato usa l'architettura spark classica, in cui il codice utente non è isolato dal motore, quindi non può applicare controlli di accesso con granularità fine senza rischiare il sovraccarico. Al contrario, il calcolo dedicato delega il filtro dei dati al calcolo serverless dell'area di lavoro, isolato da Lakeguard ed esegue il filtro per suo conto. Questo è il motivo per cui il controllo di accesso con granularità fine sul calcolo dedicato richiede che l'area di lavoro sia abilitata per il calcolo serverless. Vedere Controllo di accesso con granularità fine in calcolo dedicato.

Architettura classica di Spark

L'immagine seguente mostra come nell'architettura Spark tradizionale, le applicazioni utente condividono una JVM con accesso con privilegi al computer sottostante.

Architettura di Lakeguard

Lakeguard isola tutto il codice utente usando contenitori sicuri. Ciò consente l'esecuzione di più carichi di lavoro nella stessa risorsa di calcolo mantenendo al tempo stesso un isolamento rigoroso tra gli utenti.

Isolamento del client Spark

Lakeguard isola le applicazioni client dal driver Spark e l'una dall'altra usando due componenti chiave:

• Spark Connect: Lakeguard usa Spark Connect (introdotto con Apache Spark 3.4) per separare le applicazioni client dal driver. Le applicazioni client e i driver non condividono più la stessa JVM o classpath. Questa separazione impedisce l'accesso non autorizzato ai dati. Questa progettazione impedisce inoltre agli utenti di accedere ai dati risultanti dall'overfetching quando le query includono filtri a livello di riga o di colonna.

  Annotazioni

  Spark Connect rinvia l'analisi e la risoluzione dei nomi al tempo di esecuzione, che può modificare il comportamento del codice. Vedi Confronta Spark Connect con Spark Classic.

• Isolamento dei contenitori: Ogni applicazione client viene eseguita nel proprio contenitore isolato. Ciò impedisce al codice utente di accedere ai dati di altri utenti o al computer sottostante. Il sandboxing usa tecniche di isolamento basate su contenitori per creare limiti sicuri tra gli utenti.

Isolamento delle UDF

Per impostazione predefinita, gli executor Spark non isolano le UDF. Tale mancanza di isolamento può consentire alle UDF di scrivere file o accedere alla macchina sottostante.

Lakeguard isola il codice definito dall'utente, incluse le UDF, sugli executor Spark tramite:

• Isolamento dell'ambiente di esecuzione negli executor di Spark.
• Isolare il traffico di rete in uscita dalle UDF per impedire l'accesso esterno non autorizzato.
• Replica dell'ambiente client nella sandbox UDF in modo che gli utenti possano accedere alle librerie necessarie.

Questo isolamento si applica alle UDF su risorse di calcolo standard e alle UDF Python su risorse di calcolo serverless e SQL warehouse.