Data lake che utilizza Kerberos su Dataproc

Questo documento descrive i concetti, le best practice e l'architettura di riferimento per il networking, l'autenticazione e l'autorizzazione di un data lake Kerberized su Google Cloud utilizzando Dataproc su cluster KDC (Key Distribution Center) e Apache Ranger. Dataproc è il servizio Hadoop e Spark gestito di Google Cloud. Questo documento è destinato agli amministratori di Apache Hadoop, ai Cloud Architect e ai team di big data che stanno eseguendo la migrazione dei loro cluster Hadoop e Spark tradizionali a un data lake moderno basato su Dataproc.

Un data lake kerberizzato su Google Cloud aiuta le organizzazioni con deployment ibridi e multi-cloud a estendere e utilizzare gli investimenti IT esistenti nella gestione del controllo di identità e accessi.

Su Google Cloud, le organizzazioni possono fornire ai propri team tutti i cluster temporanei con ambito job di cui hanno bisogno. Questo approccio elimina gran parte delle complessità associate alla gestione di un singolo cluster con dipendenze e interazioni di configurazione software crescenti. Le organizzazioni possono anche creare cluster più lunghi a cui possono accedere più utenti e servizi. Questo documento mostra come utilizzare gli strumenti standard di settore, come Kerberos e Apache Ranger, per garantire una sicurezza utente granulare (autenticazione, autorizzazione e controllo) per entrambi i casi dei cluster su Dataproc.

Caso d'uso dei clienti

Le aziende stanno migrando i loro data lake on-premise basati su Hadoop a piattaforme cloud pubbliche per risolvere le sfide affrontate nella gestione dei cluster tradizionali.

Una di queste organizzazioni, un grande leader tecnologico nel settore software e hardware aziendali, ha deciso di eseguire la migrazione del proprio sistema Hadoop on-premise su Google Cloud. L'ambiente Hadoop on-premise ha soddisfatto le esigenze di analisi di centinaia di team e unità aziendali, incluso il team di cybersicurezza, che comprendeva 200 membri del team di analisi dei dati. Quando un membro del team ha eseguito una query di grandi dimensioni con il proprio data lake legacy, ha riscontrato problemi dovuti alla rigida natura delle risorse. L'organizzazione ha faticato a stare al passo con le esigenze di analisi del team utilizzando il proprio ambiente on-premise, quindi è passata a Google Cloud. Passando a Google Cloud, l'organizzazione è stata in grado di ridurre del 25% al mese il numero di problemi segnalati nel data lake on-premise.

Alla base del piano di migrazione dell'organizzazione a Google Cloud è stata la decisione di rimodellare e ottimizzare i loro grandi cluster monolitici in base ai carichi di lavoro dei team e di spostare l'attenzione dalla gestione dei cluster allo sblocco del valore aziendale. I pochi cluster di grandi dimensioni sono stati suddivisi in cluster Dataproc più piccoli ed economici, mentre i carichi di lavoro e i team sono stati migrati ai seguenti tipi di modelli:

• Cluster con ambito job temporanei: con pochi minuti di avvio, il modello temporaneo consente a un job o a un flusso di lavoro di avere un cluster dedicato che viene arrestato al completamento del job. Questo pattern disaccoppia lo spazio di archiviazione dai nodi di computing sostituendo Hadoop Distributed File System (HDFS) con Cloud Storage, utilizzando il connettore Cloud Storage per Hadoop integrato di Dataproc.
• Cluster quasi a lunga esecuzione: quando i cluster temporanei con ambito job non possono gestire il caso d'uso, i cluster Dataproc possono essere a lunga esecuzione. Quando i dati stateful del cluster vengono trasferiti in Cloud Storage, il cluster può essere facilmente arrestato e l'esecuzione viene considerata semi. La scalabilità automatica intelligente dei cluster consente inoltre a questi cluster di iniziare in piccolo 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 al cloud del suo sostanziale sistema di gestione dei dati. 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 il provider di identità (IdP) centrale on-premise basato su LDAP rimanga la fonte autorevole per le loro 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)) e su diversi altri prodotti software open source (OSS), come Apache Ranger. Questo approccio alla sicurezza consente un'autorizzazione e un controllo granulari delle attività degli utenti e dei team nei cluster dei data lake. Su Google Cloud, Identity and Access Management (IAM) viene utilizzato per gestire l'accesso a specifiche risorse Google Cloud, come Dataproc e Cloud Storage.

Questo documento illustra un approccio alla sicurezza che utilizza il meglio della sicurezza Hadoop on-premise e del software OSS (con particolare attenzione a Kerberos, LDAP aziendale e ApacheRanger) insieme a IAM per proteggere i carichi di lavoro e i dati sia all'interno che all'esterno dei cluster Hadoop.

Architettura

Il seguente diagramma mostra l'architettura di alto livello:

Nel diagramma precedente, i client eseguono job su cluster multi-team o singolo 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 del settore e IAM per autenticare e autorizzare i diversi modi di inviare i 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 secret per fornire un'autenticazione sicura per le applicazioni client/server. Il server Kerberos è noto come KDC (Key Distribution Center).

  Kerberos è ampiamente utilizzato nei sistemi on-premise come AD per autenticare utenti umani, servizi e macchine (le entità client sono indicate come principali utente). L'attivazione di Kerberos su Dataproc utilizza la distribuzione MIT di Kerberos per creare un KDC su cluster. Il KDC su cluster di Dataproc gestisce le richieste delle entità utente di accesso alle risorse all'interno del cluster, ad esempio Apache Hadoop YARN, HDFS e Apache Spark (le risorse del server sono indicate come entità di servizio). L'attendibilità tra aree di autenticazione di Kerberos ti consente di connettere le entità utente di un'area di autenticazione a un altro.

• Apache Ranger: Apache Ranger fornisce un'autorizzazione granulare agli utenti per 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 per Apache Hive e altri strumenti Hadoop. Poiché molti di questi strumenti sono basati su di esso, il metastore Hive è diventato un componente fondamentale di molti data lake. Nell'architettura proposta, un metastore Hive centralizzato e kerberizzato consente a più cluster di condividere i metadati in modo sicuro.

Mentre Kerberos, Ranger e un metastore Hive condiviso collaborano per consentire una sicurezza granulare degli utenti 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 sui bucket Cloud Storage.

Dimensioni cluster

Le seguenti dimensioni caratterizzano un cluster Dataproc:

• Tenancy: un cluster è multi-tenant se gestisce le richieste di più di un utente o servizio umano oppure di singolo tenant se gestisce le richieste di un singolo utente o servizio.
• Kerberos: un cluster può essere Kerberized se abiliti Kerberos su Dataproc o non basato su kernel se non abiliti 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 completamento del job. In caso contrario, il cluster è considerato a esecuzione semi-lunga.

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

1. I cluster multi-team di esempio mostrati nell'architettura sono cluster basati su Kerberizzati, multi-tenant e semi-lunga esecuzione. Questi cluster sono più adatti per carichi di lavoro di query interattive, ad esempio gestiscono analisi dei dati a lungo termine e esplorazione di business intelligence (BI). Nell'architettura, i cluster si trovano in un progetto Google Cloud condiviso da diversi team e che gestisce le richieste di questi team.

   In questo documento, il termine team o team applicativo descrive un gruppo di persone di un'organizzazione che lavorano sullo stesso componente software o agiscono come un unico team funzionale. Ad esempio, un team può fare riferimento agli sviluppatori backend di un microservizio, agli analisti BI di un'applicazione aziendale o persino a team interfunzionali, come i team dell'infrastruttura dei big data.

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

• Come cluster temporanei, i cluster a team singolo possono essere utilizzati per job come i data engineer per eseguire job di elaborazione batch Spark o i data scientist per un job di addestramento di modelli.

• Essendo cluster semi-lungo, i cluster a team singolo possono gestire analisi dei dati e carichi di lavoro BI con ambito a livello di singolo team o persona.

  I cluster a team singolo si trovano in progetti Google Cloud che appartengono a un unico 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 conservazione dei dati del cluster. In questo approccio, i team delle applicazioni hanno progetti dedicati, perciò i cluster a team singolo non vengono kerberizzati.

Ti consigliamo di analizzare i tuoi requisiti specifici e scegliere le combinazioni di dimensioni più adatte alla tua situazione.

Invio di job

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

• L'API Dataproc, che utilizza le chiamate REST o le librerie client.
• Lo strumento a riga di comando gcloud di Google Cloud CLI 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, ovvero una configurazione di flusso di lavoro riutilizzabile che definisce un grafico di job con informazioni su dove eseguire questi job. Se il flusso di lavoro utilizza l'opzione cluster gestito, utilizza un cluster temporaneo.
• Cloud Composer utilizzando l' operatore Dataproc. I grafi diretti aciclici (DAG) di Composer possono essere utilizzati anche per orchestrare i modelli di flusso di lavoro Dataproc.
• Apertura di una sessione SSH nel nodo master del cluster e invio diretto di un job o mediante strumenti come Apache Beeline. Questo strumento di solito è riservato solo ad amministratori e utenti esperti. Un esempio di utente esperto è uno sviluppatore che vuole risolvere i problemi relativi ai parametri di configurazione di un servizio e verificarli eseguendo job di test direttamente sul nodo master.

Networking

Il seguente diagramma evidenzia i concetti di networking dell'architettura:

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

Su Google Cloud

Su Google Cloud, l'architettura è strutturata utilizzando un VPC condiviso. 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 un VPC condiviso, devi creare 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 risorse Google Cloud correlate. Un amministratore VPC condiviso collega i progetti di servizio al progetto host per consentire l'utilizzo di subnet e risorse nella rete VPC condivisa. Questo collegamento è essenziale per consentire ai cluster di un solo team di accedere al metastore Hive centralizzato.

  Come mostrato nel diagramma Networking, consigliamo di creare progetti di servizio separati per il cluster del metastore Hive, i cluster multi-team e i cluster per ogni singolo team. I membri di ogni team della tua organizzazione possono quindi creare cluster a team singolo all'interno dei rispettivi progetti.

Per consentire la comunicazione tra i componenti all'interno della rete ibrida, devi configurare le regole del firewall per consentire il traffico seguente:

• Traffico interno del cluster per i servizi Hadoop, tra cui NameNode HDFS per comunicare con DataNodes HDFS e per YARN ResourceManager per comunicare con NodeManager YARN. Ti consigliamo di utilizzare il filtro con l'account di servizio del cluster per queste regole.
• 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) e 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 cluster di accedere alle API e ai servizi Google, devi abilitare l'accesso privato Google per le subnet dei cluster. Per consentire agli amministratori e agli utenti esperti di accedere alle istanze VM degli indirizzi IP privati, utilizza l'inoltro TCP IAP per inoltrare SSH, RDP e altro traffico su un tunnel criptato.

Alle interfacce web del cluster delle applicazioni cluster e dei componenti facoltativi (ad esempio Spark, Hadoop, Jupyter e Zeppelin) è possibile accedere in modo sicuro tramite il gateway dei componenti Dataproc. Il gateway dei componenti Dataproc è un proxy con inversione HTTP basato su Apache Knox.

On-premise

Questo documento presuppone che le risorse situate on-premise siano il servizio di directory LDAP aziendale e il KDC (Key Distribution Center) aziendale in cui sono definiti gli utenti e i responsabili del servizio del team. Se non hai bisogno di 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 aiuta a garantire che la comunicazione tra gli ambienti utilizzi indirizzi IP privati se le subnet 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 sul cluster e utilizza solo un provider di identità esterno al cluster per le identità utente. La maggior parte del traffico di autenticazione dovrebbe provenire da identità di servizio.
• Se utilizzi AD come provider di identità, i nomi delle entità utente (UPN) rappresentano gli utenti umani e gli account di servizio AD. Ti consigliamo di replicare gli UPN dall'AD on-premise in una regione Google Cloud vicina ai cluster dei tuoi data lake. Questa replica AD gestisce le richieste di autenticazione per gli UPN in modo che non siano mai in transito verso l'AD on-premise. Ogni KDC sul cluster gestisce i nomi delle entità di servizio (SPN) utilizzando la prima tecnica.

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

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

Per informazioni sul deployment di AD su Google Cloud, consulta Deployment di un ambiente Microsoft Active Directory a tolleranza di errore. Per informazioni su come dimensionare il numero di istanze per i controller di dominio, consulta Integrazione di MIT Kerberos 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.

Nel diagramma precedente, i cluster nelle aree di autenticazione Kerberos possono configurare il trust tra realm per l'utilizzo dei servizi su altri cluster, ad esempio il metastore Hive. I cluster non sottoposti a markup possono utilizzare un client Kerberos e una scheda chiavi 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 kerberizzato e il deployment del database di metastore Hive su un RDBMS remoto, ad esempio un'istanza MySQL su Cloud SQL. In quanto servizio condiviso, un cluster di 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, che è un metastore Apache Hive completamente gestito, ad alta disponibilità (all'interno di una regione), con riparazione automatica e serverless. Puoi anche attivare Kerberos per il servizio Dataproc Metastore, come spiegato in Configurare Kerberos per un servizio.

Kerberos

In questa architettura, i cluster multi-team vengono utilizzati a scopi di analisi e vengono kerberizzati seguendo la guida alla configurazione della sicurezza di Dataproc. La modalità sicura di Dataproc crea un KDC su cluster e gestisce le entità di servizio e le tabelle delle chiavi del cluster in base alla specifica della modalità sicura di Hadoop.

Una keytab è un file che contiene una o più coppie di entità Kerberos e una copia criptata della chiave di quell'entità. Un keytab consente l'autenticazione Kerberos a livello di programmazione quando non è possibile eseguire l'accesso interattivo con il comando kinit.

L'accesso a una scheda chiavi significa la possibilità di impersonare le entità contenute al suo interno. Di conseguenza, un keytab è un file altamente sensibile che deve essere trasferito e archiviato in modo sicuro. Ti consigliamo di utilizzare Secret Manager per archiviare i contenuti delle schede chiavi prima che vengano trasferiti nei rispettivi cluster. Per un esempio di come archiviare i contenuti di una keytab, consulta Configurazione di Kerberos per un servizio. Dopo il download di una scheda chiavi nel nodo master del cluster, il file deve avere autorizzazioni di accesso limitate ai file.

Il KDC su cluster gestisce le richieste di autenticazione per tutti i servizi all'interno del cluster. La maggior parte delle richieste di autenticazione dovrebbe essere di questo tipo. Per ridurre al minimo la latenza, è importante che il KDC risolva tali richieste senza che lascino il cluster.

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

In questa architettura, i cluster a team singolo non vengono kerberizzati, quindi non è presente alcun KDC. Per consentire a questi cluster di accedere al metastore Hive condiviso, devi solo installare un client Kerberos. Per automatizzare l'accesso, usa la scheda chiavi del team. Per ulteriori informazioni, consulta la sezione Mappatura delle identità più avanti in questo documento.

Trust tra realm Kerberos nei cluster multi-team

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

In Kerberos, un'area di autenticazione definisce un gruppo di sistemi in un KDC comune. L'autenticazione tra aree di autenticazione consente a un'entità utente di un'area di autenticazione di autenticarsi in un'altra area di autenticazione e di utilizzarne i servizi. Questa configurazione richiede di stabilire la fiducia tra le aree di autenticazione.

Nell'architettura ci sono tre regni:

• EXAMPLE.COM: è l'area di autenticazione aziendale, in cui sono definiti tutti i principal utente Kerberos per utenti, team e servizi (UPN).
• MULTI.EXAMPLE.COM: è l'area di autenticazione che contiene i cluster multi-team. Il cluster è preconfigurato con entità di servizio (SPN) per i servizi Hadoop, come Apache Spark e Apache Hive.
• METASTORE.EXAMPLE.COM: è un'area di autenticazione per il metastore Hive.

I cluster a team singolo non sono kerberizzati, quindi non appartengono a un'area di autenticazione.

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

• Configura l'area di autenticazione multi-team e l'area di autenticazione del metastore in modo da considerare attendibile l'area di autenticazione aziendale. Con questa configurazione, le entità definite nell'area di autenticazione aziendale possono accedere ai cluster multi-team e al metastore.

  Anche se l'attendibilità può essere transitiva, ti consigliamo di configurare l'area di autenticazione del metastore in modo che abbia un trust diretto all'area di autenticazione aziendale. Questa configurazione evita di dipendere dalla disponibilità dell'area di autenticazione multi-team.

• Configura l'area di autenticazione del metastore in modo che consideri attendibile l'area di autenticazione multi-team in modo che i cluster multi-team possano accedere al metastore. Questa configurazione è necessaria per consentire l'accesso dell'entità HiveServer2 al metastore.

Per ulteriori informazioni, consulta la pagina Introduzione ai cluster dataproc con kerberized con trust tra realm e i file di configurazione Terraform corrispondenti nel repository GitHub.

Se preferisci un approccio IAM integrato o cloud-native ai cluster multi-team e se non hai bisogno della gestione ibrida delle identità, valuta la possibilità di utilizzare l'architettura multi-tenancy 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à in cluster con un solo team

Le sezioni precedenti descrivevano la configurazione del lato kerberizzato dell'architettura. Tuttavia, i cluster a team singolo non vengono kerberizzati, quindi richiedono una tecnica speciale che consenta loro di partecipare a questo ecosistema. Questa tecnica utilizza la proprietà di separazione dei progetti Google Cloud e gli account di servizio IAM per isolare e proteggere i carichi di lavoro Hadoop dei team delle applicazioni.

Come descritto nella precedente sezione Networking, ogni team dispone di un progetto Google Cloud corrispondente in cui può creare cluster a team singolo. Nei cluster a team singolo, uno o più membri del team sono i tenant 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 ed esegue il provisioning dell'account di servizio del team in quel progetto. Quando si crea un cluster, questo account di servizio viene specificato come account di servizio del cluster.

Inoltre, crea un'entità Kerberos per il team nell'area di autenticazione aziendale e crea la scheda chiavi corrispondente. La keytab viene archiviata in modo sicuro in Secret Manager e l'amministratore copia la keytab nel nodo master del cluster. L'entità Kerberos consente l'accesso dal cluster a team singolo 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:

• Account di servizio del team: [email protected]
• Responsabile team Kerberos: revenue_reporting/[email protected]

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

Queste identità vengono utilizzate in diversi modi:

• L'identità Kerberos consente al cluster di accedere alle risorse Hadoop condivise, ad esempio il metastore Hive.
• L'account di servizio concede al cluster l'accesso alle risorse di Google Cloud condivise, come Cloud Storage.

Questa tecnica evita la necessità di creare una mappatura simile per ogni membro del team. Tuttavia, poiché questa tecnica utilizza un account di servizio o un'entità 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 (come bucket Cloud Storage, servizi gestiti e VM), un amministratore aggiunge i membri del team a un gruppo Google. L'amministratore può usare il gruppo Google per gestire le autorizzazioni IAM di accesso alle risorse cloud per l'intero team.

Quando concedi autorizzazioni IAM a un gruppo e non a singoli membri del team, semplifichi la gestione dell'accesso degli utenti quando i membri entrano a far parte del team o lo lasciano. Concedendo autorizzazioni IAM dirette al gruppo Google del team, puoi disabilitare il furto d'identità all'account di servizio, in modo da semplificare la tracciabilità delle azioni in Cloud Audit Logs. Quando definisci i membri del tuo team, ti consigliamo di bilanciare il livello di granularità richiesto per la gestione degli accessi, l'utilizzo delle risorse e il controllo con gli sforzi amministrativi derivanti da queste attività.

Se un cluster gestisce rigorosamente un utente umano (cluster a singolo tenant), invece di un team, considera l'utilizzo dell'autenticazione cluster personale di Dataproc. I cluster in cui è abilitata l'autenticazione cluster personale sono destinati solo a carichi di lavoro interattivi a breve termine da eseguire in sicurezza come un'unica identità di utente finale. Questi cluster utilizzano le credenziali dell'utente finale IAM per interagire con altre risorse Google Cloud, come Cloud Storage. Il cluster viene autenticato come utente finale, anziché come account di servizio del cluster. In questo tipo di cluster, Kerberos viene abilitato 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 loro account utente o di servizio deve avere accesso al cluster.

Quando un utente esegue un job su un cluster multi-team, sono disponibili due scelte per un'entità Kerberos, come mostrato nel diagramma seguente:

Il diagramma precedente mostra le seguenti opzioni:

1. Se l'utente utilizza uno strumento Google Cloud, come l'API Dataproc, Cloud Composer o lo strumento a riga di comando gcloud, per inviare la richiesta del job, il cluster utilizza l'entità Kerberos di Dataproc per eseguire l'autenticazione con il KDC e accedere al metastore Hive.
2. Se l'utente esegue un job da una sessione SSH, può inviare job direttamente in quella sessione utilizzando l'entità Kerberos del proprio utente.

Quando un utente esegue un job su un cluster a un unico team, esiste solo un'entità Kerberos possibile, ossia l'entità Kerberos del team, come mostrato nel seguente schema:

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

Per i cluster con un solo team, è buona norma eseguire kinit per il responsabile del team come parte di un'azione di inizializzazione al momento della creazione del cluster. Dopo la creazione del cluster, utilizza una pianificazione cron in base alla durata del ticket definita utilizzando l'opzione di comando Lifetime (-l). Per eseguire kinit, l'azione di inizializzazione scarica prima la scheda chiavi nel nodo master del cluster.

Per motivi di sicurezza, è obbligatorio 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 fino a raggiungere la durata massima del ticket. A quel punto, il job cron può riscaricare la keytab, eseguire kinit e riavviare il ciclo di rinnovo.

Sia i tipi di cluster multi-team che quelli a team utilizzano account di servizio per accedere ad altre risorse Google Cloud, come Cloud Storage. I cluster a team singolo utilizzano l'account di servizio del team come account di servizio del cluster personalizzato.

Autorizzazione

In questa sezione vengono descritti i meccanismi di autorizzazione approssimativi e granulari per ogni cluster, come mostrato nel seguente diagramma:

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

Autorizzazione granulare

IAM consente di controllare l'accesso di utenti e gruppi alle risorse del progetto. IAM definisce le autorizzazioni, nonché 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 risorse Google Cloud di cui hanno bisogno per svolgere le proprie 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 ciascun cluster, ad esempio Apache Hive o Apache Spark. Ad esempio, puoi autorizzare un determinato account ad accedere ai dati da un bucket Cloud Storage o a eseguire job. Tuttavia, non puoi specificare le colonne Hive che l'account può accedere con il job. La sezione successiva descrive come implementare questo tipo di autorizzazione granulare nei tuoi cluster.

Autorizzazione granulare

Per autorizzare un 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 è installato in ciascuno dei tuoi cluster, sia singoli che multi-team. Apache Ranger fornisce controllo dell'accesso granulare per le tue applicazioni Hadoop (autorizzazione e controllo) a livello di servizio, tabella o colonna.

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

I cluster temporanei presentano un problema perché vengono arrestati dopo il completamento dei job, ma non devono perdere i criteri e i log di amministrazione dei ranger. Per risolvere questo problema, esternalizza i criteri a un database Cloud SQL centrale ed esternalizza gli audit log alle cartelle Cloud Storage. Per ulteriori informazioni, 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 passa attraverso il seguente flusso:

1. L'utente esegue l'autenticazione 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à dell'utente è autorizzata a eseguire l'azione richiesta sul servizio specifico. Se l'identità utente può eseguire l'azione, il plug-in consente al servizio di elaborare la richiesta e l'utente riceve i risultati.
4. Ogni interazione dell'utente con un servizio Hadoop, sia consentita che negata, viene scritta nei log di Ranger da Ranger Audit Server. Ogni cluster ha la propria cartella dei log in Cloud Storage. Dataproc scrive anche i log di job e cluster che puoi visualizzare, cercare, filtrare e archiviare in Cloud Logging.

In questo documento, le architetture di riferimento utilizzavano due tipi di cluster Dataproc: cluster multi-team e cluster a team singolo. Utilizzando più cluster Dataproc di cui è facile eseguire il provisioning e proteggere la sicurezza, un'organizzazione può adottare un approccio incentrato su job, prodotto o dominio invece dei tradizionali cluster centralizzati. Questo approccio funziona bene con un'architettura complessiva di mesh di dati, che consente ai team di possedere e proteggere completamente il data lake e i suoi carichi di lavoro, nonché di offrire Data as a Service.

Passaggi successivi

• Scopri di più su come iniziare a utilizzare i cluster Dataproc con kerberized con trust tra realm e i file di configurazione Terraform corrispondenti nel repository GitHub.
• Leggi le best practice per l'utilizzo di Apache Ranger su Dataproc.
• Scopri come configurare l'accesso sicuro ai dati su Dataproc per i data analyst utilizzando strumenti di business intelligence (BI) come Tableau e Looker.
• Scopri come spostare il tuo sistema Apache Hadoop on-premise su Google Cloud.
• Scopri le best practice per la federazione di Google Cloud con un provider di identità esterno.
• Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.