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. Questa guida utilizza il termine Dataproc/Hadoop quando fa riferimento a concetti o procedure che si applicano a entrambi i tipi di deployment. La guida evidenzia i pochi casi in cui il deployment in Dataproc differisce dal deployment 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, integrata con LDAP o Active Directory
- L'autorizzazione viene fornita tramite HDFS e prodotti per la sicurezza come Apache Sentry o Apache Ranger, che assicurano agli utenti il giusto accesso alle risorse Hadoop.
- La crittografia viene fornita tramite crittografia di rete e crittografia HDFS, che insieme proteggono i dati sia in transito che at-rest.
- Il controllo è 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 daemon Hadoop HDFS e YARN, ad esempio, vengono eseguiti come utenti Unix hdfs e yarn, come spiegato in Hadoop in modalità protetta.
In genere gli utenti Hadoop vengono mappati dagli utenti del sistema Linux o dagli utenti di Active Directory/LDAP. I gruppi e gli utenti 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 offre 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 ticket Kerberos tramite il comando kinit, 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 consente a Sentry o Ranger di riconoscere la stessa mappatura dei gruppi vista dagli 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 temporanea per i dati finanziari. La cartella stg ha autorizzazioni di lettura e scrittura per il gruppo fin-loader. Da questa area temporanea, 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 dispone dell'accesso in lettura/scrittura per il gruppo fin-etl, che è l'identità utilizzata per scrivere i dati ETL, e l'accesso in 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. Le DEK non vengono mai gestite direttamente da HDFS. Al contrario, HDFS gestisce sempre 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, sono gestiti da diversi componenti Google Cloud esterni a Dataproc e Hadoop su Compute Engine.
Puoi gestire le risorse di Google Cloud utilizzando la console di Google Cloud, che è un'interfaccia basata sul Web. Puoi anche utilizzare Google Cloud CLI, che può essere più rapido e conveniente se hai dimestichezza con il lavoro dalla riga di comando. Puoi eseguire i comandi gcloud installando l'interfaccia alla gcloud CLI sul tuo computer locale oppure utilizzando un'istanza di Cloud Shell.
Autenticazione Hadoop su GCP
All'interno di Google Cloud sono disponibili due tipi di identità Google: account di servizio e account utente. La maggior parte delle API di Google richiede l'autenticazione con un'identità Google. Un numero limitato di API Google Cloud funzionerà senza autenticazione (tramite chiavi API), ma consigliamo di utilizzare tutte le API con l'autenticazione dell'account di servizio.
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 Hadoop su GCP
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 dell'accesso#39;accesso definendo quali utenti (principali) dispongono di un determinato accesso (ruolo) e per quale risorsa.
Con IAM puoi concedere l'accesso alle risorse Google Cloud e impedire l'accesso indesiderato ad altre risorse. IAM consente di implementare il principio di sicurezza del privilegio minimo, in modo da concedere solo il livello di accesso minimo necessario alle risorse.
Account di servizio
Un account di servizio è un tipo speciale di Account Google che appartiene alla tua applicazione o a una macchina virtuale (VM) invece che a un singolo utente finale. Le applicazioni possono utilizzare le credenziali dell'account di servizio per eseguire l'autenticazione con altre API Cloud. Inoltre, puoi creare regole firewall che consentono o negano il traffico da e verso le istanze in base all'account di servizio assegnato a ciascuna istanza.
I cluster Dataproc sono basati su VM di Compute Engine. L'assegnazione di un account di servizio personalizzato durante la creazione di un cluster Dataproc assegnerà tale account di servizio a tutte le VM nel cluster. In questo modo, il cluster ha accesso e controllo granulari alle risorse Google Cloud. Se non specifichi un account di servizio, le VM Dataproc utilizzano l'account di servizio Compute Engine predefinito gestito da Google. 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 account di servizio
Quando assegni un account di servizio personalizzato a un cluster Dataproc/Hadoop, il livello di accesso di tale account di servizio è determinato dalla combinazione di ambiti di accesso concessi alle istanze VM del cluster e dei ruoli IAM concessi all'account di servizio. Per configurare un'istanza utilizzando l'account di servizio personalizzato, devi configurare gli ambiti di accesso e 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 console Google Cloud, selezioni l'ambito di accesso dell'istanza:
Un cluster Dataproc o un'istanza Compute Engine hanno un insieme di ambiti di accesso definiti per l'utilizzo con l'impostazione Consenti accesso predefinito:
Esistono numerosi ambiti di accesso tra cui scegliere. Quando crei una nuova istanza VM o un nuovo cluster, ti consigliamo di impostare l'opzione Consenti l'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). Questi ambiti autorizzano l'accesso a tutti i servizi Google Cloud. Dopo aver impostato l'ambito, ti consigliamo di limitare tale accesso assegnando ruoli IAM all'account di servizio del cluster.
L'account non può eseguire alcuna azione al di fuori di questi ruoli, nonostante l'ambito di accesso di Google Cloud. Per ulteriori dettagli, consulta la documentazione sulle autorizzazioni dell'account di servizio.
Confronto tra IAM e 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 componenti di Google Cloud è definito in questi ruoli ed è associato agli account di servizio. Ciò significa che tutte le istanze che usano lo stesso account di servizio hanno lo stesso accesso ad altre risorse Google Cloud. Chiunque abbia accesso a queste istanze ha anche lo stesso accesso alle risorse Google Cloud dell'account di servizio.
I cluster Dataproc e le istanze Compute Engine non dispongono di un meccanismo per mappare gli utenti e i gruppi di Google a utenti e gruppi di Linux. Tuttavia, è possibile creare gruppi e utenti Linux. All'interno del cluster Dataproc o delle VM di Compute Engine, le autorizzazioni HDFS e la mappatura degli utenti e dei gruppi Hadoop funzionano ancora. 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 di Compute Engine devono accedere a risorse esterne come Cloud Storage o BigQuery, queste vengono autenticate come identità dell'account di servizio che hai assegnato alle VM nel cluster. Quindi, utilizzerai IAM per concedere all'account di servizio personalizzato del tuo cluster il livello di accesso minimo richiesto dalla tua applicazione.
Autorizzazioni di Cloud Storage
Dataproc utilizza Cloud Storage per il proprio sistema di archiviazione. Dataproc fornisce inoltre un sistema HDFS locale, che però non sarà disponibile se il cluster Dataproc viene eliminato. Se l'applicazione non dipende strettamente da HDFS, è preferibile utilizzare Cloud Storage per sfruttare appieno 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 da parte di account utente e account di servizio IAM può essere impostato a livello di bucket. Le autorizzazioni basate sugli utenti Linux non vengono applicate.
Crittografia Hadoop su GCP
Con alcune piccole eccezioni, i servizi Google Cloud criptano i contenuti inattivi e in transito dei clienti utilizzando una serie di metodi di crittografia. La crittografia è automatica e non è richiesta alcuna azione da parte del cliente.
Ad esempio, tutti i nuovi dati archiviati in dischi permanenti vengono criptati utilizzando l'algoritmo di crittografia avanzata (AES-256) a 256 bit e ogni chiave di crittografia viene criptata con una serie di chiavi radice (master) ruotate regolarmente. Google Cloud utilizza gli stessi criteri di crittografia e gestione delle chiavi, librerie crittografiche e la stessa radice di attendibilità utilizzate per molti servizi di produzione di Google, inclusi Gmail e i dati aziendali di Google.
Poiché la crittografia è una funzionalità predefinita di Google Cloud (a differenza della maggior parte delle implementazioni Hadoop on-premise), non devi preoccuparti di implementare la crittografia, a meno che tu non voglia utilizzare una propria chiave di crittografia. Google Cloud fornisce inoltre una soluzione di chiavi di crittografia gestita dal cliente e una soluzione di chiavi di crittografia fornite dal cliente. Se hai bisogno di gestire personalmente le chiavi di crittografia o di archiviarle on-premise, puoi farlo.
Per ulteriori dettagli, consulta Crittografia dei dati inattivi e Crittografia dei dati in transito.
Controllo Hadoop su GCP
Cloud Audit Logs può gestire alcuni tipi di log per ciascun progetto e organizzazione. I servizi Google Cloud scrivono le voci degli audit log in questi log per aiutarti a rispondere a domande come "chi ha fatto cosa, dove e quando?" nei progetti Google Cloud.
Per ulteriori informazioni sugli audit log e sui servizi che scrivono gli audit log, consulta la documentazione di Cloud Audit Logs.
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, supponiamo che tu abbia configurato il tuo ambiente Google Cloud. inclusa 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, innanzitutto crea le chiavi degli account di servizio Google Cloud e scaricale. Puoi quindi collegare il tuo modello di sicurezza POSIX e SSH on-premise al modello Google Cloud concedendo 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. Potresti avere la tentazione di spostare una piccola quantità di dati quando inizi a utilizzare Google Cloud, spostando sempre più dati 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, purché il numero di bucket sia basso.
- 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 processi di concessione delle autorizzazioni diversi. Ad esempio, la procedura per la concessione delle autorizzazioni potrebbe essere diversa per i progetti del reparto marketing e per i progetti del reparto legale.
Identificare applicazioni e creare account di servizio
Quando i cluster Dataproc/Hadoop interagiscono con altre risorse di Google Cloud, come Cloud Storage, devi identificare tutte le applicazioni che verranno eseguite su Dataproc/Hadoop e l'accesso di cui hanno bisogno. Ad esempio, immagina un job ETL che
completa 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 applicazioni hanno bisogno di accedere anche ad altri componenti di Google Cloud, come BigQuery o Cloud Bigtable, puoi concedere le autorizzazioni a questi componenti utilizzando gli account di servizio.
Ad esempio, puoi specificare operation-ca-etl come applicazione ETL per generare report sulle operazioni unendo i dati di marketing e sulle vendite della California, concedendo l'autorizzazione a scrivere report nel bucket di dati del reparto finanziario. Quindi, puoi impostare le applicazioni marketing-report-ca e sales-report-ca in modo che abbiano accesso in lettura e scrittura ai rispettivi 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 offrire 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 componenti Google Cloud in base alle autorizzazioni che hai concesso a questo account di servizio. Assicurati di fornire gli ambito di accesso corretti per l'accesso a Google Cloud e 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 uno specifico account di servizio, utilizza questo comando gcloud:
gcloud dataproc clusters create [CLUSTER_NAME] \
--service-account=[SERVICE_ACCOUNT_NAME]@[PROJECT+_ID].iam.gserviceaccount.comn \
--scopes=scope[, ...]
È meglio evitare di utilizzare l'account di servizio predefinito di Compute Engine, per i seguenti motivi:
- Se più cluster e VM di Compute Engine utilizzano l'account di servizio predefinito di Compute Engine, il controllo diventa difficile.
- L'impostazione del progetto per l'account di servizio Compute Engine predefinito può variare, il che significa che potrebbe avere più privilegi di quelli necessari per il cluster.
- Le modifiche all'account di servizio Compute Engine predefinito potrebbero interessare o interrompere involontariamente i tuoi cluster e le applicazioni eseguite al loro interno.
Valuta la possibilità di impostare 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, dati i cluster 1 e 2 nel progetto A, alcuni utenti potrebbero avere i privilegi adeguati per lavorare sul cluster 1, ma potrebbero anche avere troppe autorizzazioni per il cluster 2. O, peggio, potrebbe avere accesso al cluster 2 semplicemente perché si trova in quel progetto quando 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 i cluster in progetti più piccoli e quindi configuri IAM separatamente per ogni cluster, avrai un grado di controllo più granulare 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 utilizzando gli account di servizio protegge le interazioni tra Dataproc/Hadoop e altri componenti di Google Cloud. Tuttavia, non controlla completamente chi può accedere a Dataproc/Hadoop. Ad esempio, un utente nel cluster con l'indirizzo IP dei nodi del cluster Dataproc/Hadoop può comunque utilizzare SSH per connettersi (in alcuni casi) o per 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 o Google Cloud quando esegui Dataproc/Hadoop su Compute Engine. Tuttavia, questa guida si concentra sull'accesso a livello dei 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.
Su Google Cloud, puoi configurare limitazioni SSH a livello di utente per la connessione a istanze Compute Engine utilizzando il seguente processo:
- Attiva la funzionalità OS Login nel tuo progetto o in singole istanze.
- Concedi i ruoli IAM necessari a te e alle altre entità.
- Facoltativamente, aggiungi chiavi SSH personalizzate agli account utente per te e per altre entità. In alternativa, Compute Engine può generare automaticamente queste chiavi quando ti connetti alle istanze.
Dopo aver attivato OS Login in una o più istanze del progetto, queste istanze accettano connessioni solo dagli account utente con i ruoli IAM necessari nel progetto o nell'organizzazione.
Ad esempio, puoi concedere l'accesso alle istanze ai tuoi utenti tramite la procedura che segue:
Concedi i ruoli di accesso alle istanze necessari all'utente. 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 amministratore - Il ruolo
compute.osAdminLogin, che concede autorizzazioni di amministratore
- Il ruolo
- Il ruolo
Se sei un amministratore dell'organizzazione e vuoi consentire a identità Google esterne all'organizzazione di accedere alle tue istanze, concedi a tali identità esterne il ruolo
compute.osLoginExternalUsera livello di organizzazione. Devi inoltre concedere a queste identità esterne il ruolocompute.osLoginocompute.osAdminLogina livello di progetto o organizzazione .
Dopo aver configurato i ruoli necessari, connettiti a un'istanza tramite gli strumenti di 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 hanno bisogno di accedere a Hadoop, il che significa che la creazione di regole basate sull'IP è complessa.
- Stai eseguendo cluster Hadoop o VM client temporanei in modo che gli indirizzi IP cambino di frequente.
Utilizzando le regole firewall in combinazione con gli account di servizio, puoi impostare l'accesso a un particolare 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 il processo 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 firewall consentono a dataproc-app-1 di accedere a dataproc-1 e dataproc-2 e consentono 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 |
Target: dataproc-1Origine: [intervallo IP] Origine SA: dataproc-app-1Consenti [porte] |
dp2 |
Target: dataproc-2Origine: [intervallo IP] Origine SA: dataproc-app-2Consenti [porte] |
dp2-2 |
Target: dataproc-2Origine: [intervallo IP] Origine SA: dataproc-app-1Consenti [porte] |
app-1-client |
Target: dataproc-1Origine: [intervallo IP] Origine SA: app-1-clientConsenti [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
Disporre di regole firewall adeguate è importante anche per esporre le interfacce utente basate sul Web in esecuzione sul 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 YARN offre 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 Cloud Storage.
Esamina le configurazioni di networking 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 di destinazione in base all'account di servizio.
Funzionamento dei cluster multi-tenant
In generale, è una best practice eseguire cluster Dataproc/Hadoop separati 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 autorizzazione e 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 del genere, è preferibile raggruppare gli utenti che condividono lo stesso accesso ai dati e creare un cluster dedicato Dataproc/Hadoop. 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.