Dataproc e Google Cloud contengono diverse funzionalità che possono aiutarti a proteggere i tuoi dati. Questa guida spiega come funziona la sicurezza di Hadoop e come si traduce in Google Cloud, fornendo indicazioni su come progettare la sicurezza durante il deployment su Google Cloud.
Panoramica
Il meccanismo e il modello di sicurezza tipici di un deployment Hadoop on-premise sono diversi rispetto al meccanismo e al modello di sicurezza offerti dalla cloud. Comprendere la sicurezza su Hadoop può aiutarti a progettare meglio la sicurezza durante il deployment su Google Cloud.
Puoi eseguire il deployment di Hadoop su Google Cloud in due modi: come cluster gestiti da Google (Dataproc) o come cluster gestiti dall'utente (Hadoop su Compute Engine). La maggior parte dei contenuti e delle istruzioni tecniche in questa guida si riferisce a entrambi i tipi di deployment. In questa guida viene utilizzato il termine Dataproc/Hadoop quando si fa riferimento a concetti o procedure che si applicano a entrambi i tipi di implementazione. La guida indica i pochi casi in cui il deployment in Dataproc è diverso da quello in Hadoop su Compute Engine.
Tipica sicurezza di Hadoop on-premise
Il seguente diagramma mostra una tipica infrastruttura Hadoop on-premise e il modo in cui viene protetta. Osserva come i componenti di base di Hadoop interagiscono tra loro e con i sistemi di gestione utenti.
In generale, la sicurezza di Hadoop si basa sui seguenti quattro pilastri:
- L'autenticazione viene fornita tramite Kerberos integrato con LDAP o Active Directory
- L'autorizzazione viene fornita tramite HDFS e prodotti di sicurezza come Apache Sentry o Apache Ranger, che assicurano che gli utenti abbiano l'accesso corretto alle risorse Hadoop.
- La crittografia viene fornita tramite crittografia di rete e crittografia HDFS, che insieme proteggono i dati sia in transito sia a riposo.
- Il controllo viene fornito da prodotti forniti dal fornitore come Cloudera Navigator.
Per quanto riguarda gli account utente, Hadoop possiede una propria struttura di utenti e gruppi per gestire le identità ed eseguire i daemon. I demoni HDFS e YARN di Hadoop, ad esempio, vengono eseguiti come utenti Unix hdfs e yarn, come spiegato in Hadoop in modalità sicura.
In genere gli utenti Hadoop vengono mappati dagli utenti del sistema Linux o dagli utenti di Active Directory/LDAP. Gli utenti e i gruppi di Active Directory vengono sincronizzati da strumenti come Centrify o RedHat SSSD.
Autenticazione di Hadoop on-premise
Un sistema protetto richiede l'autenticazione di utenti e servizi di fronte al sistema. La modalità protetta di Hadoop utilizza Kerberos per l'autenticazione. La maggior parte dei componenti di Hadoop è progettata per l'utilizzo di Kerberos a tale scopo. Generalmente Kerberos viene implementato in sistemi di autenticazione aziendali come Active Directory o sistemi conformi a LDAP.
Principal di Kerberos
In Kerberos un utente viene chiamato principal. In un deployment di Hadoop esistono principal utente e principal servizio. In genere i principal utente vengono sincronizzati da Active Directory o da altri sistemi di gestione utenti a un centro di distribuzione delle chiavi (KDC). Un principal utente rappresenta un utente umano. Un principal servizio è univoco per servizio per server, pertanto ogni servizio su ogni server possiede un principal univoco che lo rappresenta.
File keytab
Un file keytab contiene i principal di Kerberos e le relative chiavi. Gli utenti e i servizi possono utilizzare i keytab per autenticarsi di fronte ai servizi Hadoop senza utilizzare strumenti interattivi e senza inserire password. Hadoop crea principal servizio per ogni servizio su ogni nodo. I principal vengono archiviati in file keytab sui nodi di Hadoop.
SPNEGO
Se stai eseguendo l'accesso a un cluster che utilizza Kerberos tramite un browser web, il browser deve essere in grado di trasmettere le chiavi di Kerberos. È qui che entra in gioco il meccanismo di negoziazione GSS-API semplice e protetto (SPNEGO), che fornisce un modo per utilizzare Kerberos nelle applicazioni web.
Integrazione
Hadoop è integrato con Kerberos non solo per l'autenticazione degli utenti, ma anche per quella dei servizi. Qualsiasi servizio Hadoop su qualsiasi nodo possiede il proprio principal di Kerberos, che viene utilizzato per l'autenticazione. In genere per i servizi sono presenti file keytab archiviati nel server, che contengono una password casuale.
Per poter interagire con i servizi, gli utenti umani in genere devono ottenere il proprio
ticket Kerberos tramite il comando kinit
o Centrify o SSSD.
Autorizzazione di Hadoop on-premise
Dopo aver convalidato un'identità, il sistema di autorizzazione controlla il tipo di accesso posseduto dall'utente o dal servizio. Su Hadoop, alcuni progetti open source come Apache Sentry e Apache Ranger vengono utilizzati per fornire le autorizzazioni.
Apache Sentry e Apache Ranger
Apache Sentry e Apache Ranger sono meccanismi di autorizzazione comuni utilizzati nei cluster Hadoop. I componenti su Hadoop implementano i propri plug-in per Sentry o Ranger per specificare il comportamento da seguire quando Sentry o Ranger confermano o negano l'accesso a un'identità. Sentry e Ranger si basano su sistemi di autenticazione come Kerberos, LDAP o AD. Il meccanismo di mappatura dei gruppi in Hadoop garantisce che Sentry o Ranger visualizzi la stessa mappatura dei gruppi degli altri componenti dell'ecosistema Hadoop.
Autorizzazioni HDFS e ACL
HDFS utilizza un sistema di autorizzazione conforme a POSIX, con un elenco di controllo di accesso (ACL) per determinare se gli utenti hanno accesso ai file. Tutti i file e le directory sono associati a un proprietario e a un gruppo. La struttura possiede una cartella radice il cui proprietario è un super user. Nei diversi livelli della struttura la crittografia può variare, così come proprietà, autorizzazioni e ACL esteso (facl).
Come mostrato nel seguente diagramma, le autorizzazioni in genere vengono concesse a livello di directory a gruppi specifici, in base alle relative esigenze di accesso. I pattern di accesso vengono identificati come ruoli diversi e vengono mappati ai gruppi di Active Directory. Gli oggetti appartenenti a un singolo set di dati di solito risiedono al livello con le autorizzazioni per un gruppo specifico, con directory diverse per diverse categorie di dati.
Ad esempio, la directory stg
è l'area di staging per i dati finanziari. La
stg
cartella dispone delle autorizzazioni di lettura e scrittura per il gruppo fin-loader
. Da questa area di staging, un altro gruppo di account dell'applicazione, fin-etl
, che rappresenta le pipeline ETL, ha accesso di sola lettura a questa directory. Le pipeline ETL
elaborano i dati e li salvano nella directory app
da pubblicare. Per abilitare questo
pattern di accesso, la directory app
ha accesso in lettura/scrittura per il gruppo fin-etl
, ovvero l'identità utilizzata per scrivere i dati ETL, e accesso di sola lettura per il gruppo fin-reader
, che utilizza i dati risultanti.
Crittografia di Hadoop on-premise
Hadoop offre alcuni metodi per criptare i dati inattivi e in transito. Per criptare i dati inattivi, è possibile criptare HDFS tramite soluzioni di crittografia delle chiavi basate su Java o soluzioni di crittografia fornite dal fornitore. HDFS supporta zone di crittografia per consentire di criptare file diversi con chiavi diverse. Ogni zona di crittografia è associata a una singola chiave della zona di crittografia, che viene specificata quando la zona viene creata.
Ogni file all'interno di una zona di crittografia possiede una chiave di crittografia dei dati (DEK) univoca. I DEK non vengono mai gestiti direttamente da HDFS. HDFS gestisce invece solo una chiave di crittografia dei dati criptata (EDEK). I client decriptano una EDEK e utilizzano la DEK risultante per leggere e scrivere i dati. I nodi di dati di HDFS visualizzano semplicemente un flusso di byte criptati.
I dati in transito tra i nodi di Hadoop possono essere criptati tramite Transport Layer Security (TLS). TLS fornisce crittografia e autenticazione nelle comunicazioni tra qualsiasi coppia di componenti di Hadoop. Generalmente Hadoop utilizza tra i componenti certificati interni per TLS firmati dalle CA.
Controllo di Hadoop on-premise
Il controllo costituisce una parte importante della sicurezza; consente di individuare attività sospette e fornisce un registro degli utenti che hanno avuto accesso alle risorse. Cloudera Navigator e altri strumenti di terze parti di solito vengono utilizzati per la gestione dei dati, ad esempio per la traccia di controllo su Hadoop. Questi strumenti forniscono visibilità e controllo sui dati nei datastore di Hadoop e sui calcoli eseguiti su tali dati. Tramite il controllo dei dati è possibile acquisire un registro completo e immutabile di tutte le attività all'interno di un sistema.
Hadoop su Google Cloud
In un ambiente Hadoop on-premise tradizionale, i quattro pilastri della sicurezza di Hadoop (autenticazione, autorizzazione, crittografia e controllo) sono integrati e gestiti da diversi componenti. In Google Cloud, vengono gestiti da diversi Google Cloud componenti esterni sia a Dataproc sia a Hadoop su Compute Engine.
Puoi gestire le Google Cloud risorse utilizzando la Google Cloud console, che è un'interfaccia basata sul web. Puoi anche utilizzare Google Cloud CLI, che può essere più veloce e pratico se hai dimestichezza con la riga di comando. Puoi eseguire i comandi gcloud installando l'interfaccia a riga di comando gcloud sul tuo computer locale o utilizzando un'istanza di Cloud Shell.
Autenticazione Google Cloud Hadoop
Esistono due tipi di identità Google Google Cloud: account di servizio e account utente. La maggior parte delle API di Google richiede l'autenticazione con un'identità Google. Un numero limitato di Google Cloud API funzionerà senza autenticazione (utilizzando le chiavi API), ma ti consigliamo di utilizzare tutte le API con l'autenticazione del service account.
Gli account di servizio utilizzano chiavi private per stabilire l'identità. Gli account utente utilizzano il protocollo OAUTH 2.0 per l'autenticazione degli utenti finali. Per ulteriori informazioni, consulta la Panoramica dell'autenticazione.
Autorizzazione Google Cloud Hadoop
Google Cloud offre diversi modi per specificare le autorizzazioni di cui dispone un'identità autenticata per un insieme di risorse.
IAM
Google Cloud offre Identity and Access Management (IAM), che ti consente di gestire il controllo degli accessi definendo quali utenti (principal) hanno quale accesso (ruolo) per quale risorsa.
Con IAM puoi concedere l'accesso alle Google Cloud risorse e impedire l'accesso indesiderato ad altre risorse. IAM ti consente di implementare il principio di sicurezza del privilegio minimo, in modo da concedere solo l'accesso minimo necessario alle tue risorse.
Account di servizio
Un account di servizio è un tipo speciale di Account Google che appartiene all'applicazione o a una macchina virtuale (VM) anziché a un singolo utente finale. Le applicazioni possono utilizzare le credenziali dell'account di servizio per autenticarsi con altre API Cloud. Inoltre, puoi creare regole firewall che consentono o rifiutano il traffico da e verso le istanze in base all'account di servizio assegnato a ogni istanza.
I cluster Dataproc sono basati su VM Compute Engine. L'assegnazione di un account di servizio personalizzato durante la creazione di un cluster Dataproc assegna questo account di servizio a tutte le VM del cluster. In questo modo, il tuo cluster avrà accesso e controllo granulare alle risorse. Google Cloud Se non specifichi un account di servizio, le VM Dataproc utilizzano il service account Compute Engine gestito da Google predefinito. Per impostazione predefinita, questo account ha il ruolo ampio di editor del progetto, grazie al quale acquisisce una vasta gamma di autorizzazioni. Ti consigliamo di non utilizzare l'account di servizio predefinito per creare un cluster Dataproc in un ambiente di produzione.
Autorizzazioni service account
Quando assegni un account di servizio personalizzato a un cluster Dataproc/Hadoop, il livello di accesso dell'account di servizio è determinato dalla combinazione di ambiti di accesso concessi alle istanze VM del cluster e dei ruoli IAM concessi al tuo account di servizio. Per configurare un'istanza utilizzando il tuo account di servizio personalizzato, devi configurare sia gli ambiti di accesso sia i ruoli IAM. In sostanza, questi meccanismi interagiscono nel seguente modo:
- Gli ambiti di accesso autorizzano l'accesso da parte di un'istanza.
- IAM limita l'accesso ai ruoli concessi all'account di servizio utilizzato dall'istanza.
- Le autorizzazioni all'intersezione degli ambiti di accesso e dei ruoli IAM sono le autorizzazioni finali dell'istanza.
Quando crei un cluster Dataproc o un'istanza Compute Engine nella Google Cloud console, seleziona l'ambito di accesso dell'istanza:
Un cluster Dataproc o un'istanza Compute Engine ha un insieme di ambiti di accesso definiti per l'utilizzo con l'impostazione Consenti accesso predefinito:
Puoi scegliere tra molti ambiti di accesso. Ti consigliamo di impostare Consenti accesso completo a tutte le API Cloud (nella console) o l'ambito di accesso https://www.googleapis.com/auth/cloud-platform
(se utilizzi Google Cloud CLI) quando crei una nuova istanza VM o un nuovo cluster. Questi ambiti autorizzano l'accesso a tutti
Google Cloud i servizi. Dopo aver impostato l'ambito, ti consigliamo di limitare l'accesso assegnando i ruoli IAM all'account di servizio del cluster.
L'account non può eseguire azioni al di fuori di questi ruoli, nonostante l'Google Cloud ambito di accesso. Per maggiori dettagli, consulta la documentazione relativa alle autorizzazioni dei service account.
Confronto dell'IAM con Apache Sentry e Apache Ranger
IAM svolge un ruolo simile ad Apache Sentry e Apache Ranger. IAM definisce l'accesso tramite i ruoli. L'accesso ad altri Google Cloud componenti è definito in questi ruoli ed è associato ai service account. Ciò significa che tutte le istanze che utilizzano lo stesso account servizio hanno lo stesso accesso ad altre Google Cloud risorse. Chiunque abbia accesso a queste istanze ha anche lo stesso accesso a queste risorseGoogle Cloud dell'account di servizio.
I cluster Dataproc e le istanze Compute Engine non hanno un meccanismo per mappare gli utenti e i gruppi Google agli utenti e ai gruppi Linux. Tuttavia, è possibile creare gruppi e utenti Linux. All'interno del cluster Dataproc o delle VM Compute Engine, le autorizzazioni HDFS e la mappatura di utenti e gruppi Hadoop continuano a funzionare. La mappatura può essere utilizzata per limitare l'accesso a HDFS o per applicare l'allocazione delle risorse tramite una coda YARN.
Quando le applicazioni su un cluster Dataproc o su una VM Compute Engine devono accedere a risorse esterne come Cloud Storage o BigQuery, queste applicazioni vengono autenticate come identità dell'account di servizio che hai assegnato alle VM del cluster. Poi, utilizza IAM per concedere all'account di servizio personalizzato del tuo cluster il livello minimo di accesso necessario per la tua applicazione.
Autorizzazioni di Cloud Storage
Dataproc utilizza Cloud Storage per il proprio sistema di archiviazione. Dataproc fornisce anche un sistema HDFS locale, ma HDFS non sarà disponibile se il cluster Dataproc viene eliminato. Se l'applicazione non dipende strettamente da HDFS, è meglio utilizzare Cloud Storage per sfruttare appieno le funzionalità di Google Cloud.
Cloud Storage non ha gerarchie di archiviazione. La struttura delle directory simula quella di un file system. Cloud Storage non ha nemmeno autorizzazioni conformi a POSIX. Il controllo dell'accesso in base agli account utente e agli account di servizio IAM può essere impostato a livello di bucket. Le autorizzazioni basate sugli utenti Linux non vengono applicate.
Crittografia Google Cloud Hadoop
Con alcune piccole eccezioni, Google Cloud i servizi criptano i contenuti dei clienti inattivi e in transito utilizzando una serie di metodi di crittografia. La crittografia è automatica e non è richiesta alcuna azione da parte del cliente.
Ad esempio, i nuovi dati memorizzati nei dischi permanenti vengono criptati utilizzando l'algoritmo AES (Advanced Encryption Standard) a 256 bit; anche ogni chiave di crittografia viene criptata utilizzando una serie di chiavi master (radice) che vengono ruotate regolarmente. Google Cloud utilizza gli stessi criteri di crittografia e gestione delle chiavi, le librerie crittografiche e la radice di attendibilità utilizzati per molti dei servizi di produzione di Google, tra cui Gmail e i dati aziendali di Google.
Poiché la crittografia è una funzionalità predefinita di Google Cloud (a differenza della maggior parte delle implementazioni di Hadoop on-premise), non devi preoccuparti di implementarla, a meno che tu non voglia utilizzare la tua chiave di crittografia.Google Cloud fornisce inoltre una soluzione per le chiavi di crittografia gestita dal cliente e una soluzione per le chiavi di crittografia fornite dal cliente. Se hai bisogno di gestire personalmente le chiavi di crittografia o di archiviarle on-premise, puoi farlo.
Per maggiori dettagli, consulta la crittografia at-rest e la crittografia dei dati in transito.
Controllo Google Cloud di Hadoop
Cloud Audit Logs può gestire alcuni tipi di log per ogni progetto e organizzazione.I servizi Google Cloud scrivono voci di audit log in questi log per aiutarti a rispondere alle domande "chi ha fatto cosa, dove e quando?" all'interno dei tuoi progettiGoogle Cloud .
Per ulteriori informazioni sui log di controllo e sui servizi che li scrivono, consulta la documentazione relativa ai log di controllo di Cloud.
Processo di migrazione
Per eseguire un'operazione sicura ed efficiente di Hadoop su Google Cloud, segui la procedura descritta in questa sezione.
In questa sezione, presupponiamo che tu abbia configurato il tuo Google Cloud ambiente. Sono inclusi la creazione di utenti e gruppi in Google Workspace. Questi utenti e gruppi vengono gestiti manualmente o sincronizzati con Active Directory e hai configurato tutto in modo che Google Cloud sia completamente funzionale in termini di autenticazione degli utenti.
Determinare chi gestisce le identità
La maggior parte dei clienti Google utilizza Cloud Identity per gestire le identità. Tuttavia, alcuni gestiscono le proprie identità aziendali indipendentemente dalle identità Google Cloud . In questo caso, l'accesso dell'utente finale alle risorse cloud è determinato dalle autorizzazioni POSIX e SSH.
Se hai un sistema di identità indipendente, inizia con la creazione Google Cloud di chiavi account di servizio e scaricale. Puoi quindi collegare il tuo modello di sicurezza POSIX e SSH on-premise al modello Google Cloud concedendo le autorizzazioni di accesso in stile POSIX appropriate ai file delle chiavi dell'account di servizio scaricati. Puoi consentire o negare alle tue identità on-premise l'accesso ai file delle chiavi.
Se segui questa procedura, la verificabilità è nelle mani dei tuoi sistemi personali di gestione delle identità. Per disporre di un audit trail, puoi utilizzare i log SSH (che custodiscono i file delle chiavi dell'account di servizio) degli accessi degli utenti sui nodi periferici; in alternativa, puoi scegliere un meccanismo di archiviazione delle chiavi più esplicito e potente per recuperare le credenziali dell'account di servizio dagli utenti. In questo caso, il "furto d'identità dell'account di servizio" viene controllato a livello di archivio chiavi.
Stabilire se utilizzare uno o più progetti per i dati
Se la tua organizzazione possiede un'ingente quantità di dati, è necessario dividerli in diversi bucket di Cloud Storage. Bisogna anche riflettere su come distribuire i bucket di dati tra i progetti. Quando inizi a utilizzare Google Cloud, potresti essere tentato di trasferire una piccola quantità di dati, per poi spostarne sempre di più man mano che i carichi di lavoro e le applicazioni si spostano.
Lasciare tutti i bucket di dati in un solo progetto può sembrare pratico, tuttavia spesso non è un approccio idoneo. Per gestire l'accesso ai dati, viene utilizzata una struttura di directory appiattita con ruoli IAM per i bucket. Tale struttura può diventare difficile da gestire con l'aumento del numero di bucket.
Un'alternativa è archiviare dati in più progetti, ognuno dei quali è dedicato a una diversa organizzazione: un progetto per il reparto finanza, un altro per il settore legale e così via. In questo caso, ogni gruppo gestisce le proprie autorizzazioni in modo indipendente.
Durante l'elaborazione dei dati, potrebbe essere necessario accedere o creare bucket ad hoc. L'elaborazione potrebbe essere suddivisa tra limiti di trust, ad esempio nel caso in cui i data scientist accedono a dati prodotti da un processo che non appartiene a loro.
Il seguente diagramma mostra una tipica organizzazione di dati in Cloud Storage in più progetti di dati e in singolo progetto di dati.
Di seguito sono riportati i principali fattori da considerare per stabilire il miglior approccio per la tua organizzazione:
Con un singolo progetto per i dati:
- È facile gestire tutti i bucket, a condizione che il numero di bucket sia ridotto.
- Nella maggior parte dei casi le autorizzazioni sono concesse dai membri del gruppo amministrativo.
Con più progetti per i dati:
- Delegare le responsabilità di gestione ai proprietari dei progetti è più semplice.
- Questo approccio è utile per le organizzazioni che hanno diversi procedimenti di concessione delle autorizzazioni. Ad esempio, la procedura di concessione delle autorizzazioni potrebbe essere diversa per i progetti del reparto marketing rispetto a quelli del reparto legale.
Identificare applicazioni e creare account di servizio
Quando i cluster Dataproc/Hadoop interagiscono con altre
Google Cloud risorse, ad esempio con Cloud Storage, devi identificarle tutte le applicazioni che verranno eseguite su Dataproc/Hadoop e
l'accesso di cui avranno bisogno. Ad esempio, immagina che esista un job ETL che compila i dati finanziari in California nel bucket financial-ca
. Il job ETL avrà bisogno di accesso in lettura/scrittura al bucket. Dopo aver identificato le applicazioni che utilizzeranno Hadoop, puoi creare account di servizio per ognuna di esse.
Tieni presente che questo accesso non influisce sugli utenti Linux all'interno del cluster Dataproc o in Hadoop su Compute Engine.
Per ulteriori informazioni sugli account di servizio, consulta la pagina sulla creazione e gestione degli account di servizio.
Concedere le autorizzazioni agli account di servizio
Quando conosci il tipo di accesso di cui ogni applicazione ha bisogno per i diversi bucket di Cloud Storage, puoi impostare le relative autorizzazioni negli account di servizio delle applicazioni pertinenti. Se le tue applicazioni devono accedere anche ad altri Google Cloud componenti, come BigQuery o Bigtable, puoi concedere le autorizzazioni anche a questi componenti utilizzando gli account di servizio.
Ad esempio, potresti specificare operation-ca-etl
come applicazione ETL per
generare report sulle operazioni assemblando i dati di marketing e vendite della
California, concedendo l'autorizzazione a scrivere report nel bucket di dati del reparto finanziario. Potresti quindi impostare le applicazioni marketing-report-ca
e sales-report-ca
in modo che ciascuna abbia accesso in lettura e scrittura ai propri reparti. Il seguente diagramma illustra tale configurazione.
È necessario seguire il principio del privilegio minimo. In base a tale principio, a ogni account di servizio o account utente vengono date solo le autorizzazioni minime necessarie per eseguire le proprie attività. Le autorizzazioni predefinite in Google Cloud sono ottimizzate per garantire facilità d'uso e ridurre i tempi di configurazione. Per creare infrastrutture Hadoop in grado di superare gli esami per la sicurezza e la conformità, devi creare autorizzazioni più restrittive. Fare investimenti già nelle fasi iniziali e documentare queste strategie è utile non solo per fornire una pipeline protetta e conforme, ma anche al momento della revisione dell'architettura con i team per la sicurezza e la conformità.
Creazione di cluster
Dopo aver pianificato e configurato l'accesso, puoi creare cluster Dataproc o Hadoop su Compute Engine con gli account di servizio che hai creato. Ogni cluster avrà accesso ad altri Google Cloud componenti in base alle autorizzazioni che hai concesso a quel service account. Assicurati di assegnare l'ambito o gli ambiti di accesso corretti per accedere a Google Cloud , quindi modificali con l'accesso all'account di servizio. Se dovesse insorgere un problema legato agli accessi, in particolare per quanto riguarda Hadoop su Compute Engine, assicurati di controllare tali autorizzazioni.
Per creare un cluster Dataproc con un account di servizio specifico, utilizza questo comando gcloud
:
gcloud dataproc clusters create [CLUSTER_NAME] \
--service-account=[SERVICE_ACCOUNT_NAME]@[PROJECT+_ID].iam.gserviceaccount.com \
--scopes=scope[, ...]
È meglio evitare di utilizzare l'account di servizio predefinito di Compute Engine, per i seguenti motivi:
- Se più cluster e VM Compute Engine utilizzano l'account di servizio Compute Engine predefinito, il controllo diventa difficile.
- L'impostazione del progetto per il service account Compute Engine predefinito può variare, il che significa che potrebbe avere più privilegi di quelli di cui ha bisogno il tuo cluster.
- Le modifiche all'account di servizio Compute Engine predefinito potrebbero influire involontariamente o addirittura interrompere i cluster e le applicazioni che li eseguono.
Valuta la possibilità di impostare le autorizzazioni IAM per ogni cluster
Posizionare numerosi cluster in un solo progetto può facilitare la loro gestione, tuttavia potrebbe non essere il miglior modo per proteggere l'accesso. Ad esempio, se sono presenti i cluster 1 e 2 nel progetto A, alcuni utenti potrebbero avere i privilegi giusti per lavorare sul cluster 1, ma anche troppe autorizzazioni per il cluster 2. O, peggio ancora, potrebbe avere accesso al cluster 2 semplicemente perché si trova nel progetto, anche se non dovrebbe avere alcun accesso.
Quando i progetti contengono numerosi cluster, l'accesso a tali cluster può diventare intricato, come mostrato nell'immagine che segue.
Se invece raggruppi cluster simili in progetti più piccoli e poi configurerai IAM separatamente per ogni cluster, avrai un grado di controllo più fine sull'accesso. Ora gli utenti hanno accesso ai cluster destinati a loro e non possono accedere agli altri.
Limitare l'accesso ai cluster
L'impostazione dell'accesso tramite account di servizio protegge le interazioni tra Dataproc/Hadoop e altri componenti. Google Cloud Tuttavia, non controlla completamente chi può accedere a Dataproc/Hadoop. Ad esempio, un utente del cluster che dispone dell'indirizzo IP dei nodi del cluster Dataproc/Hadoop può comunque utilizzare SSH per connettersi al cluster (in alcuni casi) o inviare job. Nell'ambiente on-premise l'amministratore di sistema di solito dispone di subnet, regole firewall, autenticazione Linux e altre strategie per limitare l'accesso ai cluster di Hadoop.
Esistono molti modi per limitare l'accesso a livello di autenticazione di Google Workspace oGoogle Cloud quando esegui Dataproc/Hadoop su Compute Engine. Tuttavia, questa guida si concentra sull'accesso a livello di componenti. Google Cloud
Limitare l'accesso SSH tramite OS Login
Nell'ambiente on-premise, per impedire agli utenti di connettersi a un nodo di Hadoop, devi configurare il controllo perimetrale degli accessi, l'accesso SSH a livello Linux e i file sudoers.
In Google Cloud, puoi configurare limitazioni SSH a livello di utente per la connessione alle istanze Compute Engine utilizzando la seguente procedura:
- Attiva la funzionalità di accesso al sistema operativo nel tuo progetto o nelle singole istanze.
- Concedi i ruoli IAM necessari a te e ad altri entità.
- Se vuoi, aggiungi chiavi SSH personalizzate agli account utente per te e per altri principali. In alternativa, Compute Engine può generare automaticamente queste chiavi quando ti connetti alle istanze.
Dopo aver abilitato OS Login su una o più istanze del progetto, queste istanze accettano le connessioni solo dagli account utente che dispongono dei ruoli IAM necessari nel progetto o nell'organizzazione.
Ad esempio, puoi concedere l'accesso alle istanze ai tuoi utenti tramite la procedura che segue:
Concede all'utente i ruoli di accesso alle istanze necessari. Gli utenti devono disporre dei seguenti ruoli:
- Il ruolo
iam.serviceAccountUser
Uno dei seguenti ruoli di accesso:
- Il ruolo
compute.osLogin
, che non concede autorizzazioni di amministratore - Il ruolo
compute.osAdminLogin
, che concede le autorizzazioni di amministratore
- Il ruolo
- Il ruolo
Se sei un amministratore dell'organizzazione che vuole consentire alle identità Google esterne alla tua organizzazione di accedere alle tue istanze, concedi a queste identità esterne il ruolo
compute.osLoginExternalUser
a livello di organizzazione. Devi quindi concedere a queste identità esterne il ruolocompute.osLogin
ocompute.osAdminLogin
a livello di progetto o organizzazione .
Dopo aver configurato i ruoli necessari, connettiti a un'istanza utilizzando gli strumenti Compute Engine. Compute Engine genera automaticamente chiavi SSH e le associa all'account utente.
Per ulteriori informazioni sulla funzionalità OS Login, consulta la pagina sulla gestione degli accessi a un'istanza tramite OS Login.
Limitare l'accesso alla rete tramite regole firewall
Su Google Cloud, puoi anche creare regole firewall che utilizzano gli account di servizio per filtrare il traffico in entrata o in uscita. Questo approccio può funzionare particolarmente bene nelle seguenti circostanze:
- Hai una vasta gamma di utenti o applicazioni che devono accedere a Hadoop, il che significa che creare regole in base all'IP è complicato.
- Esegui cluster Hadoop o VM client temporanei, quindi gli indirizzi IP cambiano spesso.
Utilizzando le regole firewall in combinazione con gli account di servizio, puoi impostare l'accesso a un determinato cluster Dataproc/Hadoop in modo da consentire solo un determinato account di servizio. In questo modo, solo le VM in esecuzione con tale account di servizio avranno accesso al livello specificato del cluster.
Il seguente diagramma illustra la procedura di utilizzo degli account di servizio per limitare l'accesso. dataproc-app-1
, dataproc-1
, dataproc-2
e
app-1-client
sono tutti account di servizio. Le regole di firewall consentono a dataproc-app-1
di accedere a dataproc-1
e dataproc-2
e ai client che utilizzano app-1-client
di accedere a dataproc-1
. Sul lato archiviazione, le autorizzazioni e l'accesso a Cloud Storage sono limitati dalle autorizzazioni Cloud Storage relative agli account di servizio e non dalle regole firewall.
Per questa configurazione, sono state stabilite le seguenti regole firewall:
Nome regola | Impostazioni |
---|---|
dp1 |
Destinazione: dataproc-1 Origine: [intervallo IP] SA di origine: dataproc-app-1 Consenti [porte] |
dp2 |
Destinazione: dataproc-2 Origine: [intervallo IP] SA di origine: dataproc-app-2 Consenti [porte] |
dp2-2 |
Destinazione: dataproc-2 Origine: [intervallo IP] SA di origine: dataproc-app-1 Consenti [porte] |
app-1-client |
Destinazione: dataproc-1 Origine: [intervallo IP] SA di origine: app-1-client Consenti [porte] |
Per ulteriori informazioni sull'utilizzo di regole firewall con gli account di servizio, consulta la pagina sul filtro delle origini e dei target in base all'account di servizio.
Controllare la presenza di porte firewall aperte inavvertitamente
È importante anche disporre di regole del firewall appropriate per esporre le interfacce utente basate sul web in esecuzione nel cluster. Assicurati di non avere porte firewall aperte da internet che si connettono a queste interfacce. Le porte aperte e le regole firewall configurate non correttamente possono consentire a utenti non autorizzati di eseguire codice arbitrario.
Ad esempio, Apache Hadoop YARN fornisce API REST che condividono le stesse porte delle interfacce web YARN. Per impostazione predefinita, gli utenti che possono accedere all'interfaccia web di YARN possono creare applicazioni, inviare job e potrebbero essere in grado di eseguire operazioni di Cloud Storage.
Esamina le configurazioni di rete di Dataproc. e crea un tunnel SSH. per stabilire una connessione sicura al controller del cluster. Per ulteriori informazioni sull'utilizzo delle regole firewall con gli account di servizio, consulta Filtro di origine e destinazione per account di servizio.
Funzionamento dei cluster multi-tenant
In generale, è consigliabile eseguire cluster Dataproc/Hadoop distinti per applicazioni diverse. Tuttavia, se devi utilizzare un cluster multi-tenant e non vuoi violare i requisiti di sicurezza, puoi creare utenti e gruppi Linux all'interno dei cluster Dataproc/Hadoop per fornire l'autorizzazione e l'allocazione delle risorse tramite una coda YARN. L'autenticazione deve essere implementata da te, dato che non esiste una mappatura diretta tra utenti Google e utenti Linux. L'attivazione di Kerberos sul cluster può rafforzare il livello di autenticazione nell'ambito del cluster.
A volte gli utenti umani, ad esempio un gruppo di data scientist, utilizzano un cluster di Hadoop per esplorare i dati e creare modelli. In una situazione come questa, raggruppare gli utenti che condividono lo stesso accesso ai dati e creare un cluster Dataproc/Hadoop dedicato è una buona scelta. In questo modo, puoi aggiungere utenti al gruppo che dispone dell'autorizzazione per accedere ai dati. Le risorse del cluster possono essere allocate anche in base ai relativi utenti Linux.