Gestire identità, autorizzazioni e privilegi per Lakeflow Jobs

I processi Lakeflow usano due set di autorizzazioni: privilegi di processo che controllano chi può visualizzare, eseguire e gestire un processo e i privilegi Runas che determinano l'identità usata da un processo per accedere ai dati e ad altre risorse. Questo articolo illustra entrambi, insieme alle procedure consigliate per la governance.

Nota

I segreti non vengono oscurati nei flussi stdout e stderr del driver Spark della risorsa di calcolo classica. Per proteggere i dati sensibili, per impostazione predefinita, i log dei driver Spark sono visualizzabili solo dagli utenti con l'autorizzazione CAN MANAGE per il calcolo dei processi e per le risorse di calcolo di tutti gli scopi in modalità di accesso dedicata o standard. Lo stesso valore predefinito si applica alle risorse di calcolo create da un pool. Per consentire agli utenti con l'autorizzazione CAN ATTACH TO o CAN RESTART di visualizzare i log, imposta la seguente proprietà nel campo Configurazione Spark del compute: spark.databricks.acl.needAdminPermissionToViewLogs false.

Nel compute legacy con modalità di accesso condiviso senza isolamento, i log del driver Spark possono essere visualizzati dagli utenti con l'autorizzazione CAN ATTACH TO, CAN RESTART o CAN MANAGE. Per limitare gli utenti che possono leggere i log solo agli utenti con l'autorizzazione CAN MANAGE, impostare spark.databricks.acl.needAdminPermissionToViewLogs su true.

Poiché spark.databricks.acl.needAdminPermissionToViewLogs è una proprietà Spark a livello di calcolo, è necessario impostarla in ogni ambiente di calcolo necessario. Per le esecuzioni temporanee dei processi inviati tramite jobs/runs/submit, ad esempio quelle attivate da un orchestratore esterno, impostare la proprietà in new_cluster.spark_conf al momento dell'invio, insieme a eventuali voci access_control_list.

Privilegi di processo e utente Run-as

I processi sono oggetti in Azure Databricks e dispongono di privilegi che consentono di accedere o gestire tali processi. Questa pagina descrive questi privilegi come privilegi di lavoro (o autorizzazioni).

I lavori eseguono attività per conto di un utente (o di un principale) che dispone dei propri privilegi per agire sulle risorse a cui i lavori fanno riferimento. L'utente per il quale il processo viene eseguito è chiamato utente Esegui come, e tali privilegi vengono indicati in questa pagina come privilegi Esegui come (o autorizzazioni). I privilegi dell'utente Run as vengono usati quando viene eseguita l'attività.

Ad esempio, se l'utente A crea un processo e imposta l'opzione Esegui comeutente sull'utente B, il processo viene eseguito con privilegi dell'utente B. Se l'utente C esegue il processo, il processo viene comunque eseguito con privilegi dell'utente B. Ciò significa che è possibile concedere a un utente la possibilità di eseguire un processo per ottenere informazioni dai set di dati a cui non hanno accesso.

Privilegi predefiniti per i lavori

Per impostazione predefinita, i processi hanno i privilegi seguenti:

  • All'autore del lavoro viene assegnato il permesso IS OWNER sul lavoro.
  • Agli amministratori dell'area di lavoro viene concessa l'autorizzazione "CAN MANAGE" sull'attività.
  • L'autore dell'attività è impostato per Esegui come.
  • Le autorizzazioni dell'utente Esegui come vengono usate durante l'esecuzione del processo (incluse le attività all'interno del processo).

Poiché l'impostazione predefinita consiste nell'impostare l'autore sia come proprietario sia come utente Run as, i privilegi dell'autore vengono usati quando il lavoro viene eseguito per impostazione predefinita. Databricks consiglia di modificare l'opzione Esegui come utente in un'entità servizio, in modo che i privilegi possano essere gestiti separatamente da quelli del proprietario e affinché i processi non vengano interrotti quando il proprietario lascia l'organizzazione o quando cambiano i suoi privilegi.

Autorizzazioni di amministratore per i compiti

Per impostazione predefinita, gli amministratori dell'area di lavoro possono modificare il proprietario del processo o la configurazione Esegui come per qualsiasi utente o principale del servizio nell'area di lavoro. Gli amministratori dell'account possono configurare l'impostazione RestrictWorkspaceAdmins per modificare questo comportamento. Vedere Limitare gli amministratori dell'area di lavoro.

Come i processi interagiscono con i permessi di Unity Catalog

I lavori vengono eseguiti con l'identità dell'utente nell'impostazione Esegui come. Quando si eseguono attività, questa identità viene valutata in base alle concessioni di autorizzazione per le risorse seguenti che potrebbero essere usate in tali attività:

  • Asset gestiti dal catalogo unity, tra cui tabelle, volumi, modelli e visualizzazioni.
  • Elenchi di controllo di accesso alle tabelle legacy (ACL) per gli asset registrati nel metastore Hive legacy.
  • ACL per ambiente di calcolo, notebook, query e altre risorse dell'area di lavoro.
  • Segreti di Databricks. Vedere Gestione dei segreti.

Nota

Le concessioni di Unity Catalog e gli ACL di tabella legacy richiedono modalità di accesso alle risorse di calcolo compatibili. Vedere Configurare il calcolo per i processi.

Quando vengono valutati i privilegi

I privilegi del processo vengono valutati quando un utente esegue un'azione su tale processo, ad esempio la modifica o l'esecuzione del processo.

I privilegi RunAs vengono valutati durante l'esecuzione di un processo. Ogni attività può quindi controllare i privilegi all'avvio o durante l'esecuzione.

Nota

Non tutti i privilegi Run as vengono verificati all'inizio di un'esecuzione di un job. Se si modificano i privilegi dell'utente Runas durante l'esecuzione di un processo, in particolare se si rimuovono privilegi, il processo potrebbe non riuscire prima del completamento.

Compiti e autorizzazioni SQL

L'attività file è l'unico tipo di attività SQL che rispetta completamente l'opzione Run as.

Le query SQL e gli avvisi rispettano le impostazioni di condivisione configurate.

  • Esegui come proprietario: le esecuzioni dei task SQL pianificati usano sempre l'identità del proprietario della risorsa SQL configurata.
  • Esegui come visualizzatore: Le esecuzioni pianificate dell'attività SQL utilizzano sempre l'identità definita nel campo Esegui come.

Per altre informazioni sulle impostazioni di condivisione delle query, vedere Configurare le autorizzazioni per le query.

Esempio

Lo scenario seguente illustra l'interazione delle impostazioni di condivisione SQL e l'impostazione Esegui come del processo:

  • L'utente A è il proprietario della query SQL denominata my_query.
  • L'utente A configura my_query con l'impostazione di condivisione Esegui come proprietario.
  • L'utente B programma my_query come attività in un lavoro chiamato my_job.
  • L'utente B configura my_job per l'esecuzione con un'entità servizio denominata prod_sp.
  • Quando my_job viene eseguito, usa l'identità per l'utente A per eseguire my_query.

Si supponga ora che l'utente B non desideri questo comportamento. A partire dalla configurazione esistente, si verifica quanto segue:

  • L'utente A modifica l'impostazione di condivisione di my_queryin Esegui come visualizzatore.
  • Durante l'esecuzione di my_job, usa l'identità prod_sp.

Configurare l'utente Esegui come utente per le esecuzioni dell'operazione

Per modificare l'impostazione Esegui come, è necessario disporre dell'autorizzazione PUÒ GESTIRE o È PROPRIETARIO per il processo.

Puoi impostare l'impostazione Esegui come su te stesso o su qualsiasi principale di servizio nell'area di lavoro su cui hai l'autorizzazione di Utente del Principale del Servizio.

Per configurare l'impostazione Esegui come per un processo nell'interfaccia utente dell'area di lavoro, selezionare un processo esistente seguendo i seguenti passaggi:

  1. Nella barra laterale dell'area di lavoro Azure Databricks fare clic su Jobs & Pipeline.
  2. Facoltativamente, selezionare i filtri Lavori e Di mia proprietà per semplificare la ricerca del lavoro.
  3. Fare clic sul nome dell'attività nell'elenco.
  4. Nel riquadro Dettagli processo, fare clic sull'icona della matita accanto al campo Esegui come.
  5. Cercare e selezionare un utente o un principale del servizio.
  6. Cliccare Salva.

Per ulteriori informazioni sull'uso dei principali del servizio, consulta quanto segue:

Imposta Esegui come gruppo

Importante

Questa funzionalità è in Anteprima Pubblica. Per partecipare a questa anteprima, contattare il team dell'account Azure Databricks.

Impostare l'identità Run as di un processo su un gruppo funziona allo stesso modo che impostarla su un utente o un'entità di servizio: il processo viene eseguito con le autorizzazioni di quell'identità. Quando l'identità Esegui come è un gruppo, tutte le attività vengono eseguite con il gruppo, le autorizzazioni del gruppo vengono utilizzate per l'accesso ai dati e nei log di controllo identity_metadata.run_as viene registrato come gruppo. Poiché i processi vengono sempre eseguiti dall'entità servizio applicazione del servizio Processi, identity_metadata.run_by registra sempre tale identità. Gli asset dell'area di lavoro creati durante l'esecuzione (notebook, query, file) sono di proprietà del gruppo.

Non è necessario selezionare il gruppo per impostare Esegui come su di esso. Se si crea un processo mentre si presuppone il gruppo, Azure Databricks imposta automaticamente sia il proprietario del processo che esegui come al gruppo. È anche possibile impostare Esegui come sul gruppo manualmente. Per configurare manualmente Esegui come per un gruppo, devi effettuare una delle seguenti operazioni:

  • Essere un membro del gruppo o
  • Avere l'autorizzazione Assume per il gruppo, se il gruppo viene utilizzato per l'accesso esclusivo.

Per configurare Run as per un gruppo nell'interfaccia utente dello spazio di lavoro:

  1. Nella barra laterale dell'area di lavoro Azure Databricks fare clic su Jobs & Pipeline.
  2. Fare clic sul nome dell'attività nell'elenco.
  3. Nel riquadro laterale Dettagli del processo, fare clic sull'icona della matita accanto al campo Esegui come.
  4. Cercare e selezionare il gruppo.
  5. Cliccare Salva.

Le attività vengono eseguite con il gruppo Run as per impostazione predefinita. Se la risorsa di calcolo di una singola attività è un cluster in modalità di accesso dedicato assegnato a un'identità diversa, l'attività viene eseguita invece con l'identità assegnata al cluster.

Per altre informazioni sull'uso dei gruppi come ruoli, vedere Controllo degli accessi in base al ruolo.

Pratiche migliori per la governance dei lavori

Databricks consiglia quanto segue per tutti i processi di produzione:

  • Eseguire processi di produzione con un principale del servizio

    I lavori eseguiti dall' creatore di lavori di default. Se l'utente Esegui come lascia l'organizzazione, il processo potrebbe fallire.

    Se si assegna l'utente Esegui come utente a un'entità servizio, le esecuzioni del processo usano le autorizzazioni dell'entità servizio e non cambiano quando gli utenti lasciano o hanno modificato i privilegi.

    Per impostazione predefinita, gli amministratori dell'area di lavoro possono gestire le autorizzazioni dei processi e riassegnare la titolarità, se necessario.

    L'uso dei principali di servizio per i processi di produzione consente di limitare le autorizzazioni di scrittura sui dati di produzione. Se si eseguono processi usando le autorizzazioni di un utente, tale utente deve disporre delle stesse autorizzazioni per modificare i dati di produzione richiesti dal processo.

  • usare sempre configurazioni di calcolo compatibili con Unity catalog

    La governance dei dati di Unity Catalog richiede l'uso di una configurazione di calcolo supportata.

    Le risorse di calcolo serverless per i processi e i warehouse SQL usano sempre il catalogo Unity.

    Per i processi con calcolo classico, Databricks consiglia la modalità di accesso standard per i carichi di lavoro supportati. Usare la modalità di accesso dedicato quando necessario.

    Le pipeline di Lakeflow configurate con Unity Catalog presentano alcune limitazioni. Vedere Limitazioni.

  • Limitare i privilegi lavorativi nei processi di produzione

    I privilegi delle attività controllano chi può visualizzare, eseguire o gestire le attività.

    • Gli utenti che visualizzano la configurazione del processo o monitorano le esecuzioni necessitano dell'autorizzazione Può visualizzare.
    • Gli utenti che attivano, arrestano o riavviano l'esecuzione dei processi necessitano dell'autorizzazione Può gestire l'esecuzione.
    • Concedere i privilegi Può gestire o è proprietario solo agli utenti di fiducia che sono autorizzati a modificare il codice di produzione.

Controllare l'accesso a un lavoro

Il controllo di accesso ai processi consente ai proprietari e agli amministratori di processi di concedere autorizzazioni specifiche per i processi. Sono disponibili i seguenti livelli di autorizzazione:

Nota

Ogni autorizzazione include le concessioni di autorizzazioni sottostanti nella tabella seguente.

Autorizzazione Concedere
È PROPRIETARIO Identità usata per Esegui come per impostazione predefinita. È possibile impostare l'utente Esegui come su cui eseguire l'override.
PUÒ GESTIRE Può modificare la definizione del processo, tra cui configurazione, attività e autorizzazioni. È possibile sospendere e riprendere un programma.
PUÒ GESTIRE L’ESECUZIONE Può attivare e annullare le esecuzioni di job.
PUÒ VISUALIZZARE Può visualizzare i risultati dell'esecuzione del processo, inclusi dettagli, cronologia e stato.
  • L'autore di un lavoro dispone dell'autorizzazione IS OWNER per impostazione predefinita.
  • Un lavoro non può avere più di un proprietario.
  • Non è possibile assegnare a un gruppo l'autorizzazione IS OWNER come proprietario.
  • I processi attivati tramite Esegui ora presuppongono le autorizzazioni dell'utente Runas (proprietario, per impostazione predefinita) e non dell'utente che ha emesso Run Now.
  • Il controllo di accesso ai processi si applica ai processi visualizzati nell'UI Jobs e Pipelines e alle loro esecuzioni. Non si applica a:
    • Flussi di lavoro dei notebook che eseguono codice modulare o collegato. Queste usano le autorizzazioni del notebook stesso. Se il notebook proviene da Git, viene creata una nuova copia e i relativi file ereditano le autorizzazioni dell'utente che ha attivato l'esecuzione.

    • Compiti inviati dall'API. Questi usano le autorizzazioni predefinite del notebook, a meno che non si imposti access_control_list in modo esplicito nella richiesta API.

Per informazioni sui livelli di autorizzazione dei processi, vedere ACL dei processi.

Configurare le autorizzazioni dei processi

Per configurare le autorizzazioni per un processo nell'interfaccia utente dell'area di lavoro, selezionare un processo esistente seguendo questa procedura:

  1. Nella barra laterale dell'area di lavoro Azure Databricks fare clic su Jobs & Pipeline.
  2. Opzionalmente, selezionare i filtri Attività e Di mia proprietà.
  3. Fare clic sul Nome del collegamento del proprio lavoro.
  4. Nel riquadro Dettagli processo, fare clic su Modifica autorizzazioni. Si aprirà la finestra di dialogo Impostazioni autorizzazioni.
  5. Fare clic sul campo Seleziona utente, gruppo o entità servizio... e iniziare a digitare un utente, un gruppo o un'entità servizio. Il campo cerca tutte le identità disponibili nell'area di lavoro.
  6. Cliccare Aggiungi.
  7. Cliccare Salva.

Per modificare o rimuovere un'autorizzazione esistente, fare clic su Modifica autorizzazioni per aprire la finestra di dialogo Impostazioni autorizzazioni . Per modificare un'autorizzazione, selezionare un livello diverso nell'elenco a discesa accanto all'identità. Per rimuovere un'autorizzazione, fare clic sulla x accanto all'identità.

Gestire il proprietario del compito

Solo gli amministratori del workspace possono modificare il responsabile del processo. È necessario assegnare esattamente un solo responsabile. I responsabili dei job possono essere utenti o entità del servizio.

Attività del notebook e accesso all'API

Quando si esegue un'attività notebook tramite l'interfaccia utente, l'output (all'interno del notebook) è accessibile solo se l'utente ha accesso al notebook sottostante. Tuttavia, quando lo stesso processo viene eseguito tramite l'API, l'output di esecuzione è visibile all'API, anche se l'utente dell'API ha accesso solo al processo stesso, non al notebook.