Data lake che utilizza Kerberos su Dataproc

Last reviewed 2024-04-16 UTC

Questo documento descrive i concetti, le best practice e l'architettura di riferimento per la creazione di reti, l'autenticazione e l'autorizzazione di un lake di dati Kerberized su Google Cloud utilizzando Dataproc on-cluster Key Distribution Center (KDC) e Apache Ranger. Dataproc è il servizio Hadoop e Spark gestito di Google Cloud. Questo documento è rivolto ad amministratori di Apache Hadoop, architetti cloud e team di big data che eseguono la migrazione dei loro cluster Hadoop e Spark tradizionali a un data lake moderno basato su Dataproc.

Un data lake Kerberized su Google Cloud aiuta le organizzazioni con deployment ibridi e multi-cloud a estendere e utilizzare gli investimenti IT esistenti per la gestione dell'identità e del controllo dell'accesso.

Su Google Cloud, le organizzazioni possono fornire ai propri team tutti i cluster temporanei basati sui job di cui hanno bisogno. Questo approccio elimina gran parte della complessità legata alla gestione di un singolo cluster con dipendenze crescenti e interazioni di configurazione software. Le organizzazioni possono anche creare cluster con tempi di esecuzione più lunghi a cui possono accedere più utenti e servizi. Questo documento illustra come utilizzare strumenti standard di settore, come Kerberos e Apache Ranger, per contribuire a garantire la sicurezza granulare degli utenti (autenticazione, autorizzazione e controllo) per entrambi i casi di cluster su Dataproc.

Caso d'uso del cliente

Le aziende stanno eseguendo la migrazione dei loro data lake on-premise basati su Hadoop a piattaforme cloud pubbliche per risolvere le sfide che stanno affrontando nella gestione dei loro cluster tradizionali.

Una di queste organizzazioni, un grande leader tecnologico nel software e nell'hardware aziendale, ha deciso di eseguire la migrazione del proprio sistema Hadoop on-premise a Google Cloud. Il loro ambiente Hadoop on-premise soddisfaceva le esigenze di analisi di centinaia di team e unità aziendali, incluso il team di cybersicurezza che contava 200 membri del team di analisi dei dati. Quando un membro del team ha eseguito una query di grandi dimensioni con il suo data lake legacy, ha riscontrato problemi a causa della natura rigida delle risorse. L'organizzazione non riusciva a stare al passo con le esigenze di analisi del team che utilizzava il proprio ambiente on-premise, quindi è passata a Google Cloud. Passando a Google Cloud, l'organizzazione è riuscita a ridurre il numero di problemi registrati nel proprio data lake on-premise del 25% al mese.

La base del piano di migrazione dell'organizzazione a Google Cloud è stata la decisione di riorganizzare e ottimizzare i grandi cluster monolitici in base ai carichi di lavoro dei team e di spostare l'attenzione dalla gestione dei cluster al valore dell'attività. I pochi cluster di grandi dimensioni sono stati suddivisi in cluster Dataproc più piccoli e convenienti, mentre i carichi di lavoro e i team sono stati migrati ai seguenti tipi di modelli:

  • Cluster temporanei basati su job: con un tempo di avvio di pochi minuti, il modello temporaneo consente a un job o a un flusso di lavoro di avere un cluster dedicato che viene arrestato al termine del job. Questo pattern disaccoppia lo spazio di archiviazione dai nodi di calcolo sostituendo Hadoop Distributed File System (HDFS) con Cloud Storage, utilizzando il connettore Cloud Storage per Hadoop integrato di Dataproc.
  • Cluster semi-di lunga durata: quando i cluster basati su job temporanei non possono soddisfare il caso d'uso, i cluster Dataproc possono essere di lunga durata. Quando i dati stateful del cluster vengono trasferiti a Cloud Storage, il cluster può essere facilmente arrestato e sono considerati semi-long running. La scalabilità automatica dei cluster intelligenti consente inoltre di iniziare con un numero ridotto di nodi e di ottimizzare le risorse di calcolo per applicazioni specifiche. Questa scalabilità automatica sostituisce la gestione delle code YARN.

La sfida della sicurezza ibrida

Nello scenario precedente, il cliente ha eseguito la migrazione del suo sistema di gestione dei dati di grandi dimensioni al cloud. Tuttavia, altre parti dell'IT dell'organizzazione dovevano rimanere on-premise (ad esempio alcuni dei sistemi operativi legacy che alimentano il data lake).

L'architettura di sicurezza necessaria per garantire che l'identity provider (IdP) centralizzato on-premise basato su LDAP rimanga l'origine attendibile per le identità aziendali che utilizzano il data lake. La sicurezza di Hadoop on-premise si basa su Kerberos e LDAP per l'autenticazione (spesso nell'ambito di Microsoft Active Directory (AD) dell'organizzazione) e su diversi altri prodotti software open source (OSS), come Apache Ranger. Questo approccio alla sicurezza consente l'autorizzazione e il controllo granulare delle attività degli utenti e dei team nei cluster di lake di dati. Su Google Cloud, Identity and Access Management (IAM) viene utilizzato per gestire l'accesso a risorse Google Cloud specifiche, come Dataproc e Cloud Storage.

Questo documento illustra un approccio alla sicurezza che utilizza il meglio della sicurezza Hadoop on-premise e OSS (incentrato su Kerberos, LDAP aziendale e Apache Ranger) insieme all'IAM per contribuire a proteggere i carichi di lavoro e i dati all'interno e all'esterno dei cluster Hadoop.

Architettura

Il seguente diagramma mostra l'architettura di alto livello:

L'architettura di alto livello di un data lake che utilizza Kerberos su Google Cloud utilizzando Dataproc.

Nel diagramma precedente, i client eseguono job su cluster con più team o con un solo team. I cluster utilizzano un metastore Hive centrale e l'autenticazione Kerberos con un provider di identità aziendale.

Componenti

L'architettura propone una combinazione di strumenti open source standard di settore e IAM per autenticare e autorizzare i diversi modi per inviare job descritti più avanti in questo documento. Di seguito sono riportati i componenti principali che lavorano insieme per fornire una sicurezza granulare dei carichi di lavoro di team e utenti nei cluster Hadoop:

  • Kerberos: Kerberos è un protocollo di autenticazione di rete che utilizza la crittografia con chiave segreta per fornire un'autenticazione forte per le applicazioni client/server. Il server Kerberos è noto come Key Distribution Center (KDC).

    Kerberos è ampiamente utilizzato nei sistemi on-premise come AD per autenticare persone, servizi e macchine (le entità client sono indicate come principali dell'utente). L'attivazione di Kerberos su Dataproc utilizza la distribuzione MIT di Kerberos gratuita per creare un KDC on-cluster. Il KDC on-cluster di Dataproc gestisce le richieste dei principali utente per accedere alle risorse all'interno del cluster, come Apache Hadoop YARN, HDFS e Apache Spark (le risorse del server sono indicate come principali di servizio). Il trust tra le aree di autenticazione Kerberos ti consente di collegare le entità utente di un'area di autenticazione a un'altra.

  • Apache Ranger: Apache Ranger fornisce autorizzazioni granulari per consentire agli utenti di eseguire azioni specifiche sui servizi Hadoop. Controlla inoltre l'accesso degli utenti e implementa le azioni amministrative. Ranger può sincronizzarsi con un server LDAP aziendale on-premise o con AD per ottenere le identità di utenti e servizi.

  • Metastore Hive condiviso: Il metastore Hive è un servizio che archivia i metadati di Apache Hive e di altri strumenti Hadoop. Poiché molti di questi strumenti sono basati su Hive, il metastore Hive è diventato un componente fondamentale di molti data lake. Nell'architettura proposta, un metastore Hive centralizzato e Kerberized consente a più cluster di condividere i metadati in modo sicuro.

Sebbene Kerberos, Ranger e un metastore Hive condiviso collaborino per consentire una sicurezza degli utenti granulare all'interno dei cluster Hadoop, IAM controlla l'accesso alle risorse Google Cloud . Ad esempio, Dataproc utilizza l'account di servizio Dataproc per eseguire letture e scritture nei bucket Cloud Storage.

Dimensioni del cluster

Le seguenti dimensioni caratterizzano un cluster Dataproc:

  • Tenancy: un cluster è multi-tenant se gestisce le richieste di più utenti o servizi oppure single-tenant se gestisce le richieste di un singolo utente o servizio.
  • Kerberos: un cluster può essere Kerberized se attivi Kerberos su Dataproc o non Kerberized se non attivi Kerberos su Dataproc.
  • Ciclo di vita: un cluster è temporaneo se viene creato solo per la durata di un job o flusso di lavoro specifico, contiene solo le risorse necessarie per eseguire il job e viene arrestato al termine del job. In caso contrario, il cluster viene considerato semi-long running.

Combinazioni diverse di queste dimensioni determinano i casi d'uso per i quali un cluster specifico è più adatto. Questo documento illustra i seguenti esempi rappresentativi:

  1. I cluster multi-team di esempio mostrati nell'architettura sono cluster Kerberized, multi-tenant e semi-long-running. Questi cluster sono maggiormente adatti per i carichi di lavoro di query interattive, ad esempio per l'analisi dei dati a lungo termine e l'esplorazione di business intelligence (BI). Nell'architettura, i cluster si trovano in un progetto Google Cloud condiviso da diversi team e soddisfano le richieste di questi team, da cui il nome.

    In questo documento, il termine team o team di applicazioni descrive un gruppo di persone di un'organizzazione che lavorano allo stesso componente software o agiscono come un unico team funzionale. Ad esempio, un team potrebbe fare riferimento a sviluppatori di backend di un microservice, analisti BI di un'applicazione aziendale o persino a team cross-functional, come i team di infrastruttura Big Data.

  2. I cluster a un team di esempio mostrati nell'architettura sono cluster che possono essere multi-tenant (per i membri dello stesso team) o mono-tenant.

  • Come cluster temporanei, i cluster a un team possono essere utilizzati per job come quelli eseguiti dai Data Engineer per eseguire job di elaborazione batch di Spark o dai Data Scientist per un job di addestramento del modello.
  • In quanto cluster semi-long-running, i cluster a un solo team possono gestire carichi di lavoro di analisi dei dati e BI che hanno come ambito un singolo team o una singola persona.

    I cluster a un solo team si trovano in progetti Google Cloud appartenenti a un singolo team, il che semplifica il controllo dell'utilizzo, la fatturazione e l'isolamento delle risorse. Ad esempio, solo i membri del singolo team possono accedere ai bucket Cloud Storage utilizzati per la persistenza dei dati del cluster. In questo approccio, i team di applicazioni hanno progetti dedicati, pertanto i cluster a un solo team non sono Kerberized.

Ti consigliamo di analizzare i tuoi requisiti specifici e di scegliere le migliori combinazioni di dimensioni per la tua situazione.

Invio dei job

Gli utenti possono inviare job a entrambi i tipi di cluster utilizzando vari strumenti, tra cui:

  • L'API Dataproc, utilizzando chiamate REST o librerie client.
  • Lo strumento a riga di comando Google Cloud CLI gcloud in una finestra del terminale locale o dalla console Google Cloud in Cloud Shell, aperto in un browser locale.
  • Un modello di flusso di lavoro Dataproc, che è una configurazione del flusso di lavoro riutilizzabile che definisce un grafico di job con informazioni su dove eseguirli. Se il flusso di lavoro utilizza l'opzione cluster gestito, utilizza un cluster temporaneo.
  • Cloud Composer utilizzando l'operatore Dataproc. I grafici diretti aciclici (DAG) di Composer possono essere utilizzati anche per orchestrare i modelli di flusso di lavoro di Dataproc.
  • Aprendo una sessione SSH nel nodo principale del cluster e inviando un job direttamente o utilizzando strumenti come Apache Beeline. Questo strumento è solitamente riservato solo ad amministratori e utenti esperti. Un esempio di utente avanzato è uno sviluppatore che vuole risolvere i problemi relativi ai parametri di configurazione di un servizio e verificarli eseguendo job di test direttamente sul nodo principale.

Networking

Il seguente diagramma mette in evidenza i concetti di networking dell'architettura:

Un'architettura di rete che utilizza un modello di mesh ibrido.

Nel diagramma precedente, l'architettura di rete utilizza un modello ibrido mesh, in cui alcune risorse si trovano su Google Cloude altre su on-premise. Il pattern ibrido mesh utilizza un VPC condiviso, con un progetto host comune e progetti separati per ogni tipo di cluster Dataproc e team. L'architettura è descritta in dettaglio nelle sezioni On Google Cloud e On-premise che seguono.

Il giorno Google Cloud

In Google Cloud, l'architettura è strutturata utilizzando una VPC condivisa. Un VPC condiviso consente alle risorse di più progetti di connettersi a una rete VPC comune. L'utilizzo di una rete VPC comune consente alle risorse di comunicare tra loro in modo sicuro ed efficiente utilizzando gli indirizzi IP interni di quella rete. Per configurare una rete VPC condivisa, crea i seguenti progetti:

  • Progetto host: il progetto host contiene una o più reti VPC condivise utilizzate da tutti i progetti di servizio.
  • Progetti di servizio: un progetto di servizio contiene risorseGoogle Cloud correlate. Un amministratore VPC condiviso collega i progetti di servizio al progetto host per consentire loro di utilizzare le subnet e le risorse nella rete VPC condivisa. Questo allegato è essenziale per consentire ai cluster a un solo team di accedere al metastore Hive centralizzato.

    Come mostrato nel diagramma Networking, consigliamo di creare progetti di servizi distinti per il cluster del metastore Hive, i cluster di più team e i cluster per ogni singolo team. I membri di ogni team della tua organizzazione possono quindi creare cluster di un solo team all'interno dei rispettivi progetti.

Per consentire la comunicazione tra i componenti della rete ibrida, devi configurare le regole del firewall in modo da consentire il seguente traffico:

  • Traffico cluster interno per i servizi Hadoop, tra cui NameNode HDFS per comunicare con i DataNode HDFS e Resource Manager YARN per comunicare con i NodeManager YARN. Per queste regole ti consigliamo di utilizzare la filtrazione con l'account di servizio del cluster.
  • Traffico del cluster esterno su porte specifiche per comunicare con il metastore Hive (porta tcp:9083,8020), il KDC on-premise (porta tcp:88) e LDAP (porta 636), nonché con altri servizi esterni centralizzati che utilizzi nel tuo scenario specifico, ad esempio Kafka su Google Kubernetes Engine (GKE).

Tutti i cluster Dataproc in questa architettura vengono creati solo con indirizzi IP interni. Per consentire ai nodi del cluster di accedere alle API e ai servizi Google, devi attivare l'accesso privato Google per le subnet del cluster. Per consentire agli amministratori e agli utenti esperti di accedere alle istanze VM con indirizzo IP privato, utilizza l'inoltro TCP IAP per inoltrare SSH, RDP e altro traffico tramite un tunnel criptato.

Le interfacce web del cluster delle applicazioni del cluster e dei componenti facoltativi (ad esempio Spark, Hadoop, Jupyter e Zeppelin) sono accessibili in modo sicuro tramite il gateway dei componenti Dataproc. Il gateway dei componenti Dataproc è un proxy HTTP-inverting basato su Apache Knox.

On-premise

Questo documento presuppone che le risorse on-premise siano il servizio directory LDAP aziendale e il KDC (Key Distribution Center) Kerberos aziendale in cui sono definiti gli entità di servizio utente e di gruppo. Se non devi utilizzare un provider di identità on-premise, puoi semplificare la configurazione utilizzando Cloud Identity e un KDC su un cluster Dataproc o su una macchina virtuale.

Per comunicare con LDAP e KDC on-premise, utilizza Cloud Interconnect o Cloud VPN. Questa configurazione contribuisce ad assicurare che la comunicazione tra gli ambienti utilizzi indirizzi IP privati se le sottoreti nell'indirizzo IP RFC 1918 non si sovrappongono. Per ulteriori informazioni sulle diverse opzioni di connessione, consulta Scegliere un prodotto per la connettività di rete.

In uno scenario ibrido, le richieste di autenticazione devono essere gestite con una latenza minima. Per raggiungere questo obiettivo, puoi utilizzare le seguenti tecniche:

  • Gestisci tutte le richieste di autenticazione per le identità di servizio dal KDC nel cluster e utilizza un provider di identità esterno al cluster solo per le identità utente. La maggior parte del traffico di autenticazione dovrebbe essere costituita da richieste provenienti da identità di servizio.
  • Se utilizzi AD come provider di identità, gli UPN (User Principal Name) rappresentano gli utenti e gli account di servizio AD. Ti consigliamo di replicare gli UPN dal tuo AD on-premise in una Google Cloud regione vicina ai tuoi cluster di lake di dati. Questa replica di AD gestisce le richieste di autenticazione per gli UPN, pertanto le richieste non passano mai al tuo AD on-premise. Ogni KDC nel cluster gestisce i nomi entità di servizio (SPN) utilizzando la prima tecnica.

Il seguente diagramma mostra un'architettura che utilizza entrambe le tecniche:

Un AD on-premise sincronizza gli UPN con una replica AD, mentre un KDC on-cluster autentica gli UPN e gli SPN.

Nel diagramma precedente, un AD on-premise sincronizza gli UPN con una replica AD in una Google Cloud regione. La replica AD autentica le UPN e un KDC on-cluster autentica le SPN.

Per informazioni su come eseguire il deployment di AD su Google Cloud, consulta Eseguire il deployment di un ambiente Microsoft Active Directory a tolleranza di errore. Per informazioni su come determinare le dimensioni del numero di istanze per i controller di dominio, consulta Integrare Kerberos MIT e Active Directory.

Autenticazione

Il seguente diagramma mostra i componenti utilizzati per autenticare gli utenti nei diversi cluster Hadoop. L'autenticazione consente agli utenti di utilizzare servizi come Apache Hive o Apache Spark.

I componenti autenticano gli utenti in diversi cluster Hadoop.

Nel diagramma precedente, i cluster nei realm Kerberos possono configurare la fiducia tra realm per utilizzare i servizi su altri cluster, ad esempio il metastore Hive. I cluster non Kerberos possono utilizzare un client Kerberos e una keytab dell'account per utilizzare i servizi su altri cluster.

Metastore Hive condiviso e protetto

Il metastore Hive centralizzato consente a più cluster che eseguono diversi motori di query open source, come Apache Spark, Apache Hive/Beeline e Presto, di condividere i metadati.

Esegui il deployment del server metastore Hive su un cluster Dataproc Kerberized e del database metastore Hive su un RDBMS remoto, ad esempio un'istanza MySQL su Cloud SQL. In qualità di servizio condiviso, un cluster metastore Hive gestisce solo le richieste autenticate. Per ulteriori informazioni sulla configurazione del metastore Hive, consulta Utilizzo di Apache Hive su Dataproc.

Anziché il metastore Hive, puoi utilizzare Dataproc Metastore, un metastore Apache Hive serverless completamente gestito, ad alta disponibilità (all'interno di una regione) e con riparazione automatica. Puoi anche attivare Kerberos per il servizio Dataproc Metastore, come spiegato in Configurazione di Kerberos per un servizio.

Kerberos

In questa architettura, i cluster multi-team vengono utilizzati per scopi di analisi e sono Kerberized seguendo la guida alla configurazione della sicurezza di Dataproc. La modalità protetta di Dataproc crea un KDC on-cluster e gestisce le entità di servizio e le keytab del cluster come richiesto dalla specifica della modalità protetta di Hadoop.

Un file keytab contiene una o più coppie di entità Kerberos e una copia criptata della chiave dell'entità. Un file keytab consente l'autenticazione Kerberos programmatica quando l'accesso interattivo con il comando kinit non è fattibile.

L'accesso a una keytab significa la possibilità di rubare l'identità delle entità al suo interno. Pertanto, una keytab è un file altamente sensibile che deve essere trasferito e archiviato in modo sicuro. Ti consigliamo di utilizzare Secret Manager per memorizzare i contenuti delle keytab prima che vengano trasferiti ai rispettivi cluster. Per un esempio di come archiviare i contenuti di una keytab, consulta la sezione Configurazione di Kerberos per un servizio. Dopo aver scaricato una keytab nel nodo master del cluster, il file deve avere autorizzazioni di accesso ai file limitate.

Il KDC on-cluster gestisce le richieste di autenticazione per tutti i servizi all'interno di quel cluster. La maggior parte delle richieste di autenticazione dovrebbe essere di questo tipo. Per ridurre al minimo la latenza, è importante che il KDC risolva queste richieste senza che escano dal cluster.

Le richieste rimanenti provengono da utenti e account di servizio AD. La replica AD su Google Cloud o il fornitore di ID centrale on-premise gestisce queste richieste, come spiegato nella precedente sezione On-premise.

In questa architettura, i cluster a un solo team non sono Kerberized, pertanto non è presente alcun KDC. Per consentire a questi cluster di accedere al metastore Hive condiviso, basta installare un client Kerberos. Per automatizzare l'accesso, puoi utilizzare la chiave del team. Per ulteriori informazioni, consulta la sezione Mappatura delle identità più avanti in questo documento.

Trust tra aree di autenticazione Kerberos in cluster multi-team

La fiducia tra i realm è molto pertinente quando i carichi di lavoro sono ibridi o multi-cloud. La fiducia tra i realm ti consente di integrare le identità aziendali centrali nei servizi condivisi disponibili nel tuo Google Cloud data lake.

In Kerberos, un realm definisce un gruppo di sistemi in un KDC comune. L'autenticazione tra domini consente a un principale utente di un dominio di autenticharsi in un altro dominio e di utilizzare i relativi servizi. Questa configurazione richiede di stabilire la fiducia tra i realm.

Nell'architettura sono presenti tre ambiti:

  • EXAMPLE.COM: è il realm aziendale, in cui sono definiti tutti i principali entità utente Kerberos per utenti, team e servizi (UPN).
  • MULTI.EXAMPLE.COM: è il realm che contiene i cluster di più team. Il cluster è preconfigurato con i principali servizi (SPN) per i servizi Hadoop, come Apache Spark e Apache Hive.
  • METASTORE.EXAMPLE.COM: è un realm per il metastore Hive.

I cluster a un solo team non sono Kerberized, pertanto non appartengono a un realm.

Per poter utilizzare le entità utente aziendali in tutti i cluster, devi stabilire i seguenti trust tra realm unidirezionali:

  • Configura l'area di autenticazione multi-team e l'area di autenticazione del metastore per fidarti dell'area di autenticazione aziendale. Con questa configurazione, i principali definiti nel dominio aziendale possono accedere ai cluster e al metastore multi-team.

    Sebbene la fiducia possa essere transitiva, consigliamo di configurare il realm del metastore in modo che abbia un'associazione diretta con il realm aziendale. Questa configurazione evita di dipendere dalla disponibilità del realm multiteam.

  • Configura il realm del metastore in modo che attenda il realm multi-team in modo che i cluster multi-team possano accedere al metastore. Questa configurazione è necessaria per consentire all'entità principale HiveServer2 di accedere al metastore.

Per ulteriori informazioni, consulta Guida introduttiva ai cluster dataproc Kerberized con attendibilità tra realm, e i relativi file di configurazione Terraform nel repository GitHub.

Se preferisci un approccio IAM integrato o native cloud per i cluster di più team e se non hai bisogno di gestione delle identità ibrida, ti consigliamo di utilizzare la multitenancy sicura basata su account di servizio Dataproc. In questi cluster, più identità IAM possono accedere a Cloud Storage e ad altre risorse Google come account di servizio diversi.

Mappatura delle identità nei cluster a un team

Le sezioni precedenti descrivono la configurazione del lato Kerberized dell'architettura. Tuttavia, i cluster a un solo team non sono Kerberized, pertanto richiedono una tecnica speciale per poter partecipare a questo ecosistema. Questa tecnica utilizza la proprietà di separazione dei progetti Google Cloud e gli account di servizio IAM per isolare e contribuire a proteggere i carichi di lavoro Hadoop dei team di applicazioni.

Come descritto nella precedente sezione Networking, ogni team ha un progetto Google Cloud corrispondente in cui può creare cluster di un solo team. All'interno dei cluster a un team, uno o più membri del team sono gli utenti del cluster. Questo metodo di segregazione per progetti limita anche l'accesso ai bucket Cloud Storage (utilizzati da questi cluster) ai rispettivi team.

Un amministratore crea il progetto di servizio e esegue il provisioning del service account del team in quel progetto. Quando crei un cluster, questo account di servizio viene specificato come account di servizio del cluster.

L'amministratore crea anche un'entità Kerberos per il team nel Regno aziendale e il relativo file keytab. Il file keytab viene archiviato in modo sicuro in Secret Manager e l'amministratore lo copia nel nodo master del cluster. Il principale Kerberos consente l'accesso dal cluster a un team al metastore Hive.

Per facilitare il provisioning automatico e riconoscere facilmente queste coppie di identità correlate, le identità devono seguire una convenzione di denominazione comune, ad esempio:

  • Service account di gruppo: revenue-reporting-app@proj-A.iam.gserviceaccount.com
  • Entità di gruppo Kerberos: revenue_reporting/app@EXAMPLE.COM

Questa tecnica di mappatura delle identità offre un approccio unico per mappare un'identità Kerberos a un account di servizio, entrambi appartenenti allo stesso team.

Queste identità vengono utilizzate in modi diversi:

  • L'identità Kerberos concede al cluster l'accesso alle risorse Hadoop condivisi, come il metastore Hive.
  • L'account di servizio concede al cluster l'accesso alle risorseGoogle Cloud condivise, come Cloud Storage.

Questa tecnica evita di dover creare una mappatura simile per ogni membro del team. Tuttavia, poiché questa tecnica utilizza un account servizio o un principale Kerberos per l'intero team, le azioni nel cluster Hadoop non possono essere monitorate per i singoli membri del team.

Per gestire l'accesso alle risorse cloud nel progetto del team che non rientrano nell'ambito dei cluster Hadoop (ad esempio bucket Cloud Storage, servizi gestiti e VM), un amministratore aggiunge i membri del team a un gruppo Google. L'amministratore può utilizzare il gruppo Google per gestire le autorizzazioni IAM per consentire all'intero team di accedere alle risorse cloud.

Quando concedi le autorizzazioni IAM a un gruppo e non ai singoli membri del team, semplifica la gestione dell'accesso degli utenti quando i membri si uniscono o lasciano il team dell'applicazione. Se concedi autorizzazioni IAM dirette al gruppo Google del team, puoi disattivare l'usurpazione di identità dell'account di servizio, il che contribuisce a semplificare la tracciabilità delle azioni in Cloud Audit Logs. Quando definisci i membri del tuo team, ti consigliamo di bilanciare il livello di granularità necessario per la gestione dell'accesso, l'utilizzo delle risorse e il controllo con le attività amministrative derivanti da queste attività.

Se un cluster serve esclusivamente un utente umano (un cluster monoutente), anziché un team, ti consigliamo di utilizzare l'autenticazione cluster personale Dataproc. I cluster con l'autenticazione cluster personale abilitata sono destinati solo ai carichi di lavoro interattivi a breve termine da eseguire in sicurezza come un'unica identità utente finale. Questi cluster utilizzano le credenziali utente finale IAM per interagire con altre Google Cloud risorse, come Cloud Storage. Il cluster si autentica come utente finale anziché come account di servizio del cluster. In questo tipo di cluster, Kerberos viene attivato e configurato automaticamente per la comunicazione sicura all'interno del cluster personale.

Flusso di autenticazione

Per eseguire un job su un cluster Dataproc, gli utenti hanno a disposizione molte opzioni, come descritto nella sezione precedente Invio di job. In tutti i casi, il suo account utente o account di servizio deve avere accesso al cluster.

Quando un utente esegue un job su un cluster multi-team, sono disponibili due opzioni per un principale Kerberos, come mostrato nel seguente diagramma:

Le identità Kerberos e cloud vengono utilizzate con i cluster multi-team.

Il diagramma precedente mostra le seguenti opzioni:

  1. Se l'utente utilizza uno Google Cloud strumento, ad esempio l'API Dataproc, Cloud Composer o lo strumento a riga di comando gcloud, per inviare la richiesta di job, il cluster utilizza il principale Kerberos di Dataproc per autenticarsi con il KDC e accedere al metastore Hive.
  2. Se l'utente esegue un job da una sessione SSH, può inviare i job direttamente nella sessione utilizzando il proprio principale Kerberos utente.

Quando un utente esegue un job su un cluster di un solo team, esiste un solo possibile principale Kerberos, ovvero il principale Kerberos del team, come mostrato nel seguente diagramma:

Kerberos e le identità cloud vengono utilizzati con i cluster a un solo team.

Nel diagramma precedente, un job utilizza l'entità Kerberos del team quando deve accedere al metastore Hive condiviso. In caso contrario, poiché i cluster di un solo team non sono Kerberizzati, gli utenti possono avviare i job utilizzando il proprio account utente.

Per i cluster a un solo team, è buona prassi eseguire kinit per il principale del team nell'ambito di un'azione di inizializzazione al momento della creazione del cluster. Dopo la creazione del cluster, utilizza una pianificazione cron in base al lifetime del ticket definito, utilizzando l'opzione del comando lifetime (-l). Per eseguire kinit, l'azione di inizializzazione scarica prima la keytab nel node master del cluster.

Per motivi di sicurezza, è fondamentale limitare l'accesso alla keytab. Concedi le autorizzazioni di lettura POSIX solo all'account che esegue kinit. Se possibile, elimina la keytab e rinnova il token utilizzando kinit -R per estenderne la durata utilizzando un job cron finché non viene raggiunta la durata massima del ticket. A quel punto, il job cron può scaricare di nuovo la keytab, riavviare kinit e riavviare il ciclo di rinnovo.

Entrambi i tipi di cluster multi-team e a un team utilizzano service account per accedere ad altre Google Cloud risorse, come Cloud Storage. I cluster a un solo team utilizzano l'account di servizio del team come account di servizio del cluster personalizzato.

Autorizzazione

Questa sezione descrive i meccanismi di autorizzazione granulari e a livello granulare per ciascun cluster, come mostrato nel seguente diagramma:

Un'architettura di autorizzazione utilizza IAM per l'autorizzazione a livello granulare e Apache Ranger per l'autorizzazione granulare.

L'architettura nel diagramma precedente utilizza IAM per l'autorizzazione a livello granulare e Apache Ranger per l'autorizzazione granulare. Questi metodi di autorizzazione sono descritti nelle sezioni seguenti: Autorizzazione a granularità elevata e Autorizzazione a granularità fine.

Autorizzazione a livello grossolano

IAM ti consente di controllare l'accesso degli utenti e dei gruppi alle risorse del progetto. IAM definisce le autorizzazioni e i ruoli che le concedono.

Esistono quattro ruoli Dataproc predefiniti: amministratore, editor, visualizzatore e worker. Questi ruoli concedono autorizzazioni Dataproc che consentono a utenti e account di servizio di eseguire azioni specifiche su cluster, job, operazioni e modelli di flusso di lavoro. I ruoli concedono l'accesso alle Google Cloud risorse necessarie per svolgere le attività. Una di queste risorse è Cloud Storage, che consigliamo di utilizzare come livello di archiviazione del cluster anziché HDFS.

La granularità delle autorizzazioni IAM Dataproc non si estende al livello dei servizi in esecuzione su ogni cluster, come Apache Hive o Apache Spark. Ad esempio, puoi autorizzare un determinato account ad accedere ai dati di un bucket Cloud Storage o a eseguire job. Tuttavia, non puoi specificare a quali colonne Hive l'account è autorizzato ad accedere con il job. La sezione successiva descrive come implementare questo tipo di autorizzazione granulare nei cluster.

Autorizzazione granulare

Per autorizzare l'accesso granulare, utilizza il componente facoltativo Dataproc Ranger nell'architettura descritta in Best practice per l'utilizzo di Apache Ranger su Dataproc. In questa architettura, Apache Ranger viene installato in ciascuno dei tuoi cluster, sia singoli che multi-team. Apache Ranger fornisce controllo dell'accesso granulare per le applicazioni Hadoop (autorizzazione e controllo) a livello di servizio, tabella o colonna.

Apache Ranger utilizza le identità fornite dal repository LDAP aziendale e definite come entità Kerberos. Nei cluster multi-team, il daemon Ranger UserSync aggiorna periodicamente le identità Kerberized dal server LDAP aziendale. Nei cluster a un team è obbligatoria solo l'identità del team.

I cluster effimeri rappresentano una sfida perché si arrestano al termine dei job, ma non devono perdere i criteri e i log di amministrazione di Ranger. Per risolvere questo problema, esternalizza le norme in un database Cloud SQL centrale ed esternalizza i log di controllo nelle cartelle Cloud Storage. Per saperne di più, consulta le best practice per l'utilizzo di Apache Ranger su Dataproc.

Flusso di autorizzazione

Quando un utente vuole accedere a uno o più servizi del cluster per elaborare i dati, la richiesta segue il seguente flusso:

  1. L'utente si autentica tramite una delle opzioni descritte nella sezione Flusso di autenticazione.
  2. Il servizio di destinazione riceve la richiesta dell'utente e chiama il plug-in Apache Ranger corrispondente.
  3. Il plug-in recupera periodicamente i criteri dal Ranger Policy Server. Questi criteri determinano se l'identità utente è autorizzata a eseguire l'azione richiesta sul servizio specifico. Se l'identità utente è autorizzata a eseguire l'azione, il plug-in consente al servizio di elaborare la richiesta e l'utente ottiene i risultati.
  4. Ogni interazione utente con un servizio Hadoop, consentita o negata, viene scritta nei log di Ranger dal server di controllo di Ranger. Ogni cluster ha la propria cartella dei log in Cloud Storage. Dataproc scrive anche log di job e cluster che puoi visualizzare, cercare, filtrare e archiviare in Cloud Logging.

In questo documento, le architetture di riferimento utilizzano due tipi di cluster Dataproc: cluster multi-team e cluster a un team. Utilizzando più cluster Dataproc che possono essere facilmente provisionati e protetti, un'organizzazione può utilizzare un approccio incentrato su job, prodotti o domini anziché cluster centralizzati tradizionali. Questo approccio funziona bene con un'architettura complessiva di Data Mesh, che consente ai team di possedere e proteggere completamente il proprio data lake e i relativi carichi di lavoro e di offrire i dati come servizio.

Passaggi successivi