Collega il tuo software di visualizzazione a Hadoop su Google Cloud

Inizializzazione dell'ambiente

1. Nella console Google Cloud, attiva Cloud Shell.

   Attiva Cloud Shell

2. In Cloud Shell, imposta le variabili di ambiente con l'ID progetto e la regione e le zone dei cluster Dataproc:

   export PROJECT_ID=$(gcloud info --format='value(config.project)')
   export REGION=us-central1
   export ZONE=us-central1-b
   

   Puoi scegliere qualsiasi regione e zona, ma mantienile coerenti mentre segui questo tutorial.

Configurazione di un account di servizio

1. In Cloud Shell, crea un account di servizio.

   gcloud iam service-accounts create cluster-service-account \
     --description="The service account for the cluster to be authenticated as." \
     --display-name="Cluster service account"
   

   Il cluster utilizza questo account per accedere alle risorse Google Cloud.

2. Aggiungi i ruoli seguenti all'account di servizio:

   • Worker Dataproc: per creare e gestire cluster Dataproc.
   • Editor Cloud SQL: per consentire a Ranger di connettersi al suo database utilizzando il proxy Cloud SQL.

   • Autore crittografia CryptoKey Cloud KMS: per decriptare le password criptate con Cloud KMS.

     bash -c 'array=( dataproc.worker cloudsql.editor cloudkms.cryptoKeyDecrypter )
     for i in "${array[@]}"
     do
       gcloud projects add-iam-policy-binding ${PROJECT_ID} \
         --member "serviceAccount:cluster-service-account@${PROJECT_ID}.iam.gserviceaccount.com" \
         --role roles/$i
     done'
     

Creazione del cluster di backend

In questa sezione creerai il cluster di backend in cui si trova il ranger. Creerai anche il database Ranger per archiviare le regole dei criteri e una tabella di esempio in Hive per applicare i criteri dei criteri.

Crea l'istanza di database Ranger

1. Crea un'istanza MySQL per archiviare i criteri di Apache Ranger:

   export CLOUD_SQL_NAME=cloudsql-mysql
   gcloud sql instances create ${CLOUD_SQL_NAME} \
       --tier=db-n1-standard-1 --region=${REGION}
   

   Questo comando crea un'istanza denominata cloudsql-mysql con il tipo di macchina db-n1-standard-1 situato nella regione specificata dalla variabile ${REGION}. Per ulteriori informazioni, consulta la documentazione di Cloud SQL.

2. Imposta la password dell'istanza per l'utente root che si connette da qualsiasi host. Puoi utilizzare la password di esempio a scopo dimostrativo o crearne una personalizzata. Se crei la tua password, utilizza almeno otto caratteri, inclusi almeno una lettera e un numero.

   gcloud sql users set-password root \
     --host=% --instance ${CLOUD_SQL_NAME} --password mysql-root-password-99
   

Cripta le password

In questa sezione creerai una chiave di crittografia per criptare le password per Ranger e MySQL. Per evitare l'esfiltrazione, archivia la chiave di crittografia in Cloud KMS. Per motivi di sicurezza, non puoi visualizzare, estrarre o esportare i bit della chiave.

che puoi utilizzare per crittografare le password e scriverle nei file. Devi caricare questi file in un bucket Cloud Storage in modo che siano accessibili all'account di servizio che agisce per conto dei cluster. L'account di servizio può decriptare questi file perché ha il ruolo cloudkms.cryptoKeyDecrypter e l'accesso ai file e alla chiave di crittografia. Anche se un file viene esfiltrato, non può essere decriptato senza il ruolo e la chiave.

Come ulteriore misura di sicurezza, crei file di password separati per ogni servizio. Questa azione riduce al minimo l'area potenzialmente interessata dall'esfiltrazione di una password.

Per ulteriori informazioni sulla gestione delle chiavi, consulta la documentazione di Cloud KMS.

1. In Cloud Shell, crea un keyring Cloud KMS per archiviare le chiavi:

   gcloud kms keyrings create my-keyring --location global
   

2. Per criptare le password, crea una chiave di crittografia Cloud KMS:

   gcloud kms keys create my-key \
     --location global \
     --keyring my-keyring \
     --purpose encryption
   

3. Cripta la password dell'utente amministratore di Ranger utilizzando la chiave. Puoi utilizzare la password di esempio o crearne una personalizzata. La password deve essere costituita da almeno otto caratteri, inclusi almeno una lettera e un numero.

   echo "ranger-admin-password-99" | \
   gcloud kms encrypt \
     --location=global \
     --keyring=my-keyring \
     --key=my-key \
     --plaintext-file=- \
     --ciphertext-file=ranger-admin-password.encrypted
   

4. Cripta la password utente dell'amministratore del database Ranger con la chiave:

   echo "ranger-db-admin-password-99" | \
   gcloud kms encrypt \
     --location=global \
     --keyring=my-keyring \
     --key=my-key \
     --plaintext-file=- \
     --ciphertext-file=ranger-db-admin-password.encrypted
   

5. Cripta la password root di MySQL con la chiave:

   echo "mysql-root-password-99" | \
   gcloud kms encrypt \
     --location=global \
     --keyring=my-keyring \
     --key=my-key \
     --plaintext-file=- \
     --ciphertext-file=mysql-root-password.encrypted
   

6. Crea un bucket Cloud Storage per archiviare i file di password criptati:

   gsutil mb -l ${REGION} gs://${PROJECT_ID}-ranger
   

7. Carica i file delle password criptate nel bucket Cloud Storage:

   gsutil -m cp *.encrypted gs://${PROJECT_ID}-ranger
   

Crea il cluster

In questa sezione creerai un cluster di backend con il supporto di Ranger. Per ulteriori informazioni sul componente facoltativo Ranger in Dataproc, consulta la pagina della documentazione del componente Dataproc Ranger.

1. In Cloud Shell, crea un bucket Cloud Storage per archiviare gli audit log di Apache Solr:

   gsutil mb -l ${REGION} gs://${PROJECT_ID}-solr
   

2. Esporta tutte le variabili necessarie per creare il cluster:

   export BACKEND_CLUSTER=backend-cluster
   
   export PROJECT_ID=$(gcloud info --format='value(config.project)')
   export REGION=us-central1
   export ZONE=us-central1-b
   export CLOUD_SQL_NAME=cloudsql-mysql
   
   export RANGER_KMS_KEY_URI=\
   projects/${PROJECT_ID}/locations/global/keyRings/my-keyring/cryptoKeys/my-key
   
   export RANGER_ADMIN_PWD_URI=\
   gs://${PROJECT_ID}-ranger/ranger-admin-password.encrypted
   
   export RANGER_DB_ADMIN_PWD_URI=\
   gs://${PROJECT_ID}-ranger/ranger-db-admin-password.encrypted
   
   export MYSQL_ROOT_PWD_URI=\
   gs://${PROJECT_ID}-ranger/mysql-root-password.encrypted
   

   Per praticità, alcune delle variabili impostate prima sono ripetute in questo comando per poterle modificare in base alle tue esigenze.

   Le nuove variabili contengono:

   • Il nome del cluster di backend.
   • L'URI della chiave di crittografia in modo che l'account di servizio possa decriptare le password.
   • L'URI dei file contenenti le password criptate.

   Se hai utilizzato un keyring o una chiave diversi oppure nomi file diversi, utilizza i valori corrispondenti nel comando.

3. Crea il cluster Dataproc di backend:

   gcloud beta dataproc clusters create ${BACKEND_CLUSTER} \
     --optional-components=SOLR,RANGER \
     --region ${REGION} \
     --zone ${ZONE} \
     --enable-component-gateway \
     --scopes=default,sql-admin \
     --service-account=cluster-service-account@${PROJECT_ID}.iam.gserviceaccount.com \
     --properties="\
   dataproc:ranger.kms.key.uri=${RANGER_KMS_KEY_URI},\
   dataproc:ranger.admin.password.uri=${RANGER_ADMIN_PWD_URI},\
   dataproc:ranger.db.admin.password.uri=${RANGER_DB_ADMIN_PWD_URI},\
   dataproc:ranger.cloud-sql.instance.connection.name=${PROJECT_ID}:${REGION}:${CLOUD_SQL_NAME},\
   dataproc:ranger.cloud-sql.root.password.uri=${MYSQL_ROOT_PWD_URI},\
   dataproc:solr.gcs.path=gs://${PROJECT_ID}-solr,\
   hive:hive.server2.thrift.http.port=10000,\
   hive:hive.server2.thrift.http.path=cliservice,\
   hive:hive.server2.transport.mode=http"
   

   Questo comando ha le seguenti proprietà:

   • Le ultime tre righe del comando sono le proprietà Hive per configurare HiveServer2 in modalità HTTP, in modo che Apache Knox possa chiamare Apache Hive tramite HTTP.
   • Gli altri parametri nel comando funzionano come segue:
     • Il parametro --optional-components=SOLR,RANGER abilita Apache Ranger e la sua dipendenza Solr.
     • Il parametro --enable-component-gateway consente al gateway del componente Dataproc di rendere disponibili l'interfaccia utente di Ranger e altre interfacce utente di Hadoop direttamente dalla pagina del cluster nella console Google Cloud. Se imposti questo parametro, non è necessario eseguire il tunneling SSH al nodo master di backend.
     • Il parametro --scopes=default,sql-admin autorizza Apache Ranger ad accedere al relativo database Cloud SQL.

Se devi creare un metastore Hive esterno che persiste oltre la durata di qualsiasi cluster e può essere utilizzato in più cluster, consulta Utilizzo di Apache Hive su Dataproc. Per eseguire la procedura, devi eseguire gli esempi di creazione delle tabelle direttamente su Beeline. Sebbene i comandi gcloud dataproc jobs submit hive utilizzino il trasporto binario Hive, questi comandi non sono compatibili con HiveServer2 se è configurato in modalità HTTP.

Crea una tabella Hive di esempio

1. In Cloud Shell, crea un bucket Cloud Storage per archiviare un file Apache Parquet di esempio:

   gsutil mb -l ${REGION} gs://${PROJECT_ID}-hive
   

2. Copia nel bucket un file Parquet di esempio disponibile pubblicamente:

   gsutil cp gs://hive-solution/part-00000.parquet \
     gs://${PROJECT_ID}-hive/dataset/transactions/part-00000.parquet
   

3. Connettiti al nodo master del cluster di backend che hai creato nella sezione precedente utilizzando SSH:

   gcloud compute ssh --zone ${ZONE} ${BACKEND_CLUSTER}-m
   

   Il nome del nodo master del cluster è il nome del cluster seguito da -m. I nomi dei nodi master del cluster ad alta disponibilità hanno un suffisso aggiuntivo.

   Se è la prima volta che ti connetti al nodo master da Cloud Shell, ti viene chiesto di generare le chiavi SSH.

4. Nel terminale che hai aperto con SSH, connettiti all'HiveServer2 locale utilizzando Apache Beeline, preinstallato sul nodo master:

   beeline -u "jdbc:hive2://localhost:10000/;transportMode=http;httpPath=cliservice admin admin-password"\
     --hivevar PROJECT_ID=$(gcloud info --format='value(config.project)')
   

   Questo comando avvia lo strumento a riga di comando di Beeline e passa il nome del tuo progetto Google Cloud in una variabile di ambiente.

   Hive non esegue alcuna autenticazione utente, ma per eseguire la maggior parte delle attività richiede un'identità utente. L'utente admin qui è un utente predefinito configurato in Hive. Il provider di identità che configurerai con Apache Knox più avanti in questo tutorial gestisce l'autenticazione utente per eventuali richieste provenienti dagli strumenti BI.

5. Nel prompt di Beeline, crea una tabella utilizzando il file Parquet che hai precedentemente copiato nel bucket Hive:

   CREATE EXTERNAL TABLE transactions
     (SubmissionDate DATE, TransactionAmount DOUBLE, TransactionType STRING)
     STORED AS PARQUET
     LOCATION 'gs://${PROJECT_ID}-hive/dataset/transactions';
   

6. Verifica che la tabella sia stata creata correttamente:

   SELECT *
     FROM transactions
     LIMIT 10;
   
   SELECT TransactionType, AVG(TransactionAmount) AS AverageAmount
     FROM transactions
     WHERE SubmissionDate = '2017-12-22'
     GROUP BY TransactionType;
   

   I risultati delle due query vengono visualizzati nel prompt di Beeline.

7. Esci dallo strumento a riga di comando di Beeline:

   !quit
   

8. Copia il nome DNS interno del master di backend:

   hostname -A | tr -d '[:space:]'; echo
   

   Dovrai utilizzare questo nome nella prossima sezione come backend-master-internal-dns-name per configurare la topologia Apache Knox. Potrai usare il nome anche per configurare un servizio nel ranger.

9. Esci dal terminale sul nodo:

   exit
   

Creazione del cluster proxy in corso...

In questa sezione creerai il cluster proxy che contiene l'azione di inizializzazione di Apache Knox.

Crea una topologia

1. In Cloud Shell, clona il repository GitHub di azioni di inizializzazione di Dataproc:

   git clone https://github.com/GoogleCloudDataproc/initialization-actions.git
   

2. Crea una topologia per il cluster di backend:

   export KNOX_INIT_FOLDER=`pwd`/initialization-actions/knox
   cd ${KNOX_INIT_FOLDER}/topologies/
   mv example-hive-nonpii.xml hive-us-transactions.xml
   

   Apache Knox utilizza il nome del file come percorso dell'URL per la topologia. In questo passaggio, modificherai il nome per rappresentare una topologia denominata hive-us-transactions. Puoi quindi accedere ai dati delle transazioni fittizi che hai caricato in Hive in Creare una tabella Hive di esempio

3. Modifica il file della topologia:

   vi hive-us-transactions.xml
   

   Per vedere come sono configurati i servizi di backend, consulta il file del descrittore della topologia. Questo file definisce una topologia che punta a uno o più servizi di backend. Due servizi sono configurati con valori di esempio: WebHDFS e HIVE. Il file definisce anche il provider di autenticazione per i servizi in questa topologia e gli ACL di autorizzazione.

4. Aggiungi l'identità utente LDAP di esempio del data analyst sara.

   <param>
      <name>hive.acl</name>
      <value>admin,sara;*;*</value>
   </param>
   

   L'aggiunta dell'identità di esempio consente all'utente di accedere al servizio di backend Hive tramite Apache Knox.

5. Modifica l'URL HIVE in modo che punti al servizio Hive del cluster di backend. Puoi trovare la definizione del servizio HIVE nella parte inferiore del file, in WebHDFS.

   <service>
     <role>HIVE</role>
     <url>http://<backend-master-internal-dns-name>:10000/cliservice</url>
   </service>
   

6. Sostituisci il segnaposto <backend-master-internal-dns-name> con il nome del DNS interno del cluster di backend che hai acquisito in Creare una tabella Hive di esempio.

7. Salva il file e chiudi l'editor.

Per creare altre topologie, ripeti i passaggi in questa sezione. Crea un descrittore XML indipendente per ogni topologia.

In Crea il cluster proxy copi questi file in un bucket Cloud Storage. Per creare nuove topologie o modificarle dopo aver creato il cluster proxy, modifica i file e caricali nuovamente nel bucket. L'azione di inizializzazione di Apache Knox crea un cron job che copia regolarmente le modifiche dal bucket al cluster proxy.

Configura il certificato SSL/TLS

Un client utilizza un certificato SSL/TLS quando comunica con Apache Knox. L'azione di inizializzazione può generare un certificato autofirmato oppure puoi fornire il tuo certificato firmato dall'autorità di certificazione.

1. In Cloud Shell, modifica il file di configurazione generale di Apache Knox:

   vi ${KNOX_INIT_FOLDER}/knox-config.yaml
   

2. Sostituisci HOSTNAME con il nome DNS esterno del tuo nodo master del proxy come valore dell'attributo certificate_hostname. Per questo tutorial, utilizza localhost.

   certificate_hostname: localhost
   

   Più avanti in questo tutorial, crei un tunnel SSH e il cluster proxy per il valore localhost.

   Il file di configurazione generale di Apache Knox contiene anche master_key, che cripta i certificati utilizzati dagli strumenti BI per comunicare con il cluster proxy. Per impostazione predefinita, questa chiave è la parola secret.

3. Se intendi fornire il tuo certificato, modifica le due proprietà seguenti:

   generate_cert: false
   custom_cert_name: <filename-of-your-custom-certificate>
   

4. Salva il file e chiudi l'editor.

   Se fornisci il tuo certificato, puoi specificarlo nella proprietà custom_cert_name.

Crea il cluster proxy

1. In Cloud Shell, crea un bucket Cloud Storage:

   gsutil mb -l ${REGION} gs://${PROJECT_ID}-knox
   

   Questo bucket fornisce le configurazioni create nella sezione precedente all'azione di inizializzazione di Apache Knox.

2. Copia tutti i file dalla cartella delle azioni di inizializzazione di Apache Knox nel bucket:

   gsutil -m cp -r ${KNOX_INIT_FOLDER}/* gs://${PROJECT_ID}-knox
   

3. Esporta tutte le variabili necessarie per creare il cluster:

   export PROXY_CLUSTER=proxy-cluster
   export PROJECT_ID=$(gcloud info --format='value(config.project)')
   export REGION=us-central1
   export ZONE=us-central1-b
   

   In questo passaggio, alcune delle variabili impostate in precedenza vengono ripetute in modo da poter apportare le modifiche necessarie.

4. Crea il cluster proxy:

   gcloud dataproc clusters create ${PROXY_CLUSTER} \
     --region ${REGION} \
     --zone ${ZONE} \
     --service-account=cluster-service-account@${PROJECT_ID}.iam.gserviceaccount.com \
     --initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/knox/knox.sh \
     --metadata knox-gw-config=gs://${PROJECT_ID}-knox
   

Verifica la connessione tramite proxy

1. Dopo aver creato il cluster proxy, utilizza SSH per connetterti al nodo master da Cloud Shell:

   gcloud compute ssh --zone ${ZONE} ${PROXY_CLUSTER}-m
   

2. Dal terminale del nodo master del cluster proxy, esegui la query seguente:

   beeline -u "jdbc:hive2://localhost:8443/;\
   ssl=true;sslTrustStore=/usr/lib/knox/data/security/keystores/gateway-client.jks;trustStorePassword=secret;\
   transportMode=http;httpPath=gateway/hive-us-transactions/hive"\
     -e "SELECT SubmissionDate, TransactionType FROM transactions LIMIT 10;"\
     -n admin -p admin-password
   

Questo comando ha le seguenti proprietà:

• Il comando beeline utilizza localhost anziché il nome interno del DNS perché il certificato che hai generato durante la configurazione di Apache Knox specifica localhost come nome host. Se utilizzi il tuo nome o certificato DNS, usa il nome host corrispondente.
• La porta è 8443, che corrisponde alla porta SSL predefinita di Apache Knox.
• La riga che inizia ssl=true abilita SSL e fornisce il percorso e la password dell'archivio di attendibilità SSL, che deve essere utilizzato dalle applicazioni client come Beeline.
• La riga transportMode indica che la richiesta deve essere inviata tramite HTTP e fornisce il percorso per il servizio HiveServer2. Il percorso è composto dalla parola chiave gateway, dal nome della topologia che hai definito in una sezione precedente e dal nome del servizio configurato nella stessa topologia, in questo caso hive.
• Il parametro -e fornisce la query da eseguire su Hive. Se ometti questo parametro, apri una sessione interattiva nello strumento a riga di comando di Beeline.
• Il parametro -n fornisce un'identità utente e una password. In questo passaggio, utilizzi l'utente Hive admin predefinito. Nelle sezioni successive, creerai un'identità utente analista e imposterai le credenziali e i criteri di autorizzazione per questo utente.

Aggiungi un utente all'archivio di autenticazione

Per impostazione predefinita, Apache Knox include un provider di autenticazione basato su Apache Shiro. Questo provider di autenticazione è configurato con l'autenticazione BASIC rispetto a un archivio LDAP ApacheDS. In questa sezione, aggiungerai l'identità utente di un analista di dati di esempio sara all'archivio di autenticazione.

1. Dal terminale nel nodo master del proxy, installa le utilità LDAP:

   sudo apt-get install ldap-utils
   

2. Crea un file LDIF (LDAP Data Interchange Format) per il nuovo utente sara:

   export USER_ID=sara
   
   printf '%s\n'\
     "# entry for user ${USER_ID}"\
     "dn: uid=${USER_ID},ou=people,dc=hadoop,dc=apache,dc=org"\
     "objectclass:top"\
     "objectclass:person"\
     "objectclass:organizationalPerson"\
     "objectclass:inetOrgPerson"\
     "cn: ${USER_ID}"\
     "sn: ${USER_ID}"\
     "uid: ${USER_ID}"\
     "userPassword:${USER_ID}-password"\
   > new-user.ldif
   

3. Aggiungi l'ID utente alla directory LDAP:

   ldapadd -f new-user.ldif \
     -D 'uid=admin,ou=people,dc=hadoop,dc=apache,dc=org' \
     -w 'admin-password' \
     -H ldap://localhost:33389
   

   Il parametro -D specifica il nome distinto (DN) da associare quando l'utente rappresentato da ldapadd accede alla directory. Il DN deve essere un'identità utente già presente nella directory, in questo caso l'utente admin.

4. Verifica che il nuovo utente si trovi nell'archivio autenticazione:

   ldapsearch -b "uid=${USER_ID},ou=people,dc=hadoop,dc=apache,dc=org" \
     -D 'uid=admin,ou=people,dc=hadoop,dc=apache,dc=org' \
     -w 'admin-password' \
     -H ldap://localhost:33389
   

   I dettagli dell'utente vengono visualizzati nel terminale.

5. Copia e salva il nome DNS interno del nodo master del proxy:

   hostname -A | tr -d '[:space:]'; echo
   

   Userai questo nome nella prossima sezione come <proxy-master-internal-dns-name> per configurare la sincronizzazione LDAP.

6. Esci dal terminale sul nodo:

   exit
   

Configurazione dell'autorizzazione

In questa sezione configurerai la sincronizzazione delle identità tra il servizio LDAP e il ranger.

Sincronizza le identità degli utenti in Ranger

Per assicurarti che i criteri di Ranger si applichino alle stesse identità utente di Apache Knox, devi configurare il daemon UserSync di Ranger per sincronizzare le identità dalla stessa directory.

In questo esempio, ti connetti alla directory LDAP locale disponibile per impostazione predefinita con Apache Knox. Tuttavia, in un ambiente di produzione, ti consigliamo di configurare una directory delle identità esterna. Per ulteriori informazioni, consulta la Guida dell'utente di Apache Knox e la documentazione di Google Cloud Cloud Identity, Managed Active Directory e Federated AD.

1. Utilizzando SSH, connettiti al nodo master del cluster di backend che hai creato:

   export BACKEND_CLUSTER=backend-cluster
   gcloud compute ssh --zone ${ZONE} ${BACKEND_CLUSTER}-m
   

2. Nel terminale, modifica il file di configurazione UserSync:

   sudo vi /etc/ranger/usersync/conf/ranger-ugsync-site.xml
   

3. Imposta i valori delle seguenti proprietà LDAP. Assicurati di modificare le proprietà user e non le proprietà group, che hanno nomi simili.

   <property>
     <name>ranger.usersync.sync.source</name>
     <value>ldap</value>
   </property>
   
   <property>
     <name>ranger.usersync.ldap.url</name>
     <value>ldap://<proxy-master-internal-dns-name>:33389</value>
   </property>
   
   <property>
     <name>ranger.usersync.ldap.binddn</name>
     <value>uid=admin,ou=people,dc=hadoop,dc=apache,dc=org</value>
   </property>
   
   <property>
     <name>ranger.usersync.ldap.ldapbindpassword</name>
     <value>admin-password</value>
   </property>
   
   <property>
     <name>ranger.usersync.ldap.user.searchbase</name>
     <value>dc=hadoop,dc=apache,dc=org</value>
   </property>
   
   <property>
     <name>ranger.usersync.source.impl.class</name>
     <value>org.apache.ranger.ldapusersync.process.LdapUserGroupBuilder</value>
   </property>
   

   Sostituisci il segnaposto <proxy-master-internal-dns-name> con il nome del DNS interno del server proxy, recuperato nell'ultima sezione.

   Queste proprietà sono un sottoinsieme di una configurazione LDAP completa che sincronizza sia utenti che gruppi. Per ulteriori informazioni, consulta Come integrare Ranger con LDAP.

4. Salva il file e chiudi l'editor.

5. Riavvia il daemon ranger-usersync:

   sudo service ranger-usersync restart
   

6. Esegui questo comando:

   grep sara /var/log/ranger-usersync/*
   

   Se le identità sono sincronizzate, viene visualizzata almeno una riga di log per l'utente sara.

Creazione dei criteri di Ranger

In questa sezione configurerai un nuovo servizio Hive in Ranger. Puoi anche configurare e testare un criterio Ranger per limitare l'accesso ai dati di Hive per un'identità specifica.

Configura il servizio Ranger

1. Nel terminale del nodo master, modifica la configurazione di Ranger Hive:

   sudo vi /etc/hive/conf/ranger-hive-security.xml
   

2. Modifica la proprietà <value> della proprietà ranger.plugin.hive.service.name:

   <property>
      <name>ranger.plugin.hive.service.name</name>
      <value>ranger-hive-service-01</value>
      <description>
        Name of the Ranger service containing policies for this YARN instance
      </description>
   </property>
   

3. Salva il file e chiudi l'editor.

4. Riavvia il servizio di amministrazione HiveServer2:

   sudo service hive-server2 restart
   

   Ora puoi creare criteri dei ranger.

Configurare il servizio nella Console di amministrazione di Ranger

1. Nella console Google Cloud, vai alla pagina Dataproc.

2. Fai clic sul nome del cluster di backend, quindi su Interfacce web.

   Poiché hai creato il cluster con Gateway dei componenti, vedrai un elenco dei componenti Hadoop installati nel cluster.

3. Fai clic sul link Ranger per aprire la console di Ranger.

4. Accedi a Ranger con l'utente admin e la tua password di amministratore del ranger. La console Ranger mostra la pagina Gestore servizi con un elenco di servizi.

5. Fai clic sul segno più nel gruppo HIVE per creare un nuovo servizio Hive.

   

6. Nel modulo, imposta i seguenti valori:

   • Nome del servizio: ranger-hive-service-01. In precedenza hai definito questo nome nel file di configurazione ranger-hive-security.xml.
   • Nome utente: admin
   • Password: admin-password
   • jdbc.driverClassName: mantieni il nome predefinito su org.apache.hive.jdbc.HiveDriver
   • jdbc.url: jdbc:hive2:<backend-master-internal-dns-name>:10000/;transportMode=http;httpPath=cliservice
   • Sostituisci il segnaposto <backend-master-internal-dns-name> con il nome recuperato in una sezione precedente.

7. Fai clic su Aggiungi.

   Ogni installazione di plug-in Ranger supporta un singolo servizio Hive. Un modo semplice per configurare servizi Hive aggiuntivi è avviare cluster di backend aggiuntivi. Ogni cluster ha il proprio plug-in Ranger. Questi cluster possono condividere lo stesso database Ranger, in modo da avere una visualizzazione unificata di tutti i servizi ogni volta che accedi alla Console di amministrazione Ranger da uno di questi cluster.

Configurare un criterio dei ranger con autorizzazioni limitate

Il criterio consente all'utente LDAP dell'analista di esempio sara di accedere a colonne specifiche della tabella Hive.

1. Nella finestra Gestore servizi, fai clic sul nome del servizio che hai creato.

   Nella Console di amministrazione di Ranger è visualizzata la finestra Criteri.

2. Fai clic su Aggiungi nuova norma.

   Con questo criterio, autorizzi sara a visualizzare solo le colonne submissionDate e transactionType delle transazioni della tabella.

3. Nel modulo, imposta i seguenti valori:

   • Nome del criterio: qualsiasi nome, ad esempio allow-tx-columns
   • Database: default
   • Tabella: transactions
   • Colonna Hive: submissionDate, transactionType
   • Condizioni di autorizzazione:
     • Seleziona l'utente: sara
     • Autorizzazioni: select

4. Nella parte inferiore dello schermo, fai clic su Aggiungi.

Testa il criterio con Beeline

1. Nel terminale del nodo master, avvia lo strumento a riga di comando Beeline con l'utente sara.

   beeline -u "jdbc:hive2://localhost:10000/;transportMode=http;httpPath=cliservice sara user-password"
   

   Anche se lo strumento a riga di comando di Bee non applica la password, devi fornire una password per eseguire il comando precedente.

2. Esegui la query seguente per verificare che Ranger lo blocchi.

    SELECT *
      FROM transactions
      LIMIT 10;
   

   La query include la colonna transactionAmount, che sara non ha l'autorizzazione per selezionare.

   Viene visualizzato un errore di Permission denied.

3. Verifica che Ranger consenta la query seguente:

   SELECT submissionDate, transactionType
     FROM transactions
     LIMIT 10;
   

4. Esci dallo strumento a riga di comando di Beeline:

   !quit
   

5. Esci dal terminale:

   exit
   

6. Nella console Ranger, fai clic sulla scheda Controllo. Vengono visualizzati entrambi gli eventi negati e consentiti. Puoi filtrare gli eventi in base al nome del servizio definito in precedenza, ad esempio ranger-hive-service-01.

   

Connessione da uno strumento BI

Il passaggio finale di questo tutorial consiste nell'eseguire una query sui dati Hive da Tableau Desktop.

Crea una regola firewall

1. Copia e salva il tuo indirizzo IP pubblico.

2. In Cloud Shell, crea una regola firewall che apra la porta TCP 8443 per il traffico in entrata dalla workstation:

   gcloud compute firewall-rules create allow-knox\
     --project=${PROJECT_ID} --direction=INGRESS --priority=1000 \
     --network=default --action=ALLOW --rules=tcp:8443 \
     --target-tags=knox-gateway \
     --source-ranges=<your-public-ip>/32
   

   Sostituisci il segnaposto <your-public-ip> con il tuo indirizzo IP pubblico.

3. Applica il tag di rete dalla regola firewall al nodo master del cluster proxy:

   gcloud compute instances add-tags ${PROXY_CLUSTER}-m --zone=${ZONE} \
     --tags=knox-gateway
   

Crea un tunnel SSH

Questa procedura è necessaria solo se utilizzi un certificato autofirmato valido per localhost. Se stai utilizzando il tuo certificato o il nodo master del proxy ha un proprio nome DNS esterno, puoi passare a Connetti a Hive.

1. In Cloud Shell, genera il comando per creare il tunnel:

   echo "gcloud compute ssh ${PROXY_CLUSTER}-m \
     --project ${PROJECT_ID} \
     --zone ${ZONE} \
     -- -L 8443:localhost:8443"
   

2. Esegui gcloud init per autenticare il tuo account utente e concedere le autorizzazioni di accesso.

3. Apri un terminale nella workstation.

4. Crea un tunnel SSH per inoltrare la porta 8443. Copia il comando generato nel primo passaggio e incollalo nel terminale di workstation, quindi esegui il comando.

5. Lascia aperto il terminale in modo che il tunnel resti attivo.

Connetti a Hive

1. Sulla workstation, installa il driver Hive ODBC.
2. Apri Tableau Desktop o riavvialo se era aperto.
3. Nella home page, sotto Connetti / a un server, seleziona Altro.
4. Cerca e seleziona Cloudera Hadoop.

5. Utilizzando l'utente LDAP sara dell'analista di dati di esempio come identità, compila i campi come segue:

   • Server: se hai creato un tunnel, utilizza localhost. Se non hai creato un tunnel, utilizza il nome DNS esterno del nodo master del proxy.
   • Porta: 8443
   • Tipo: HiveServer2
   • Autenticazione: Username e Password
   • Nome utente: sara
   • Password: sara-password
   • Percorso HTTP: gateway/hive-us-transactions/hive
   • SSL obbligatorio: yes

6. Fai clic su Accedi.

   

Esegui query sui dati Hive

1. Nella schermata Origine dati, fai clic su Seleziona schema e cerca default.

2. Fai doppio clic sul nome dello schema default.

   Viene caricato il riquadro Tabella.

3. Nel riquadro Tabella, fai doppio clic su Nuovo SQL personalizzato.

   Viene visualizzata la finestra Modifica SQL personalizzato.

4. Inserisci la seguente query, che seleziona la data e il tipo di transazione dalla tabella delle transazioni:

   SELECT `submissiondate`,
          `transactiontype`
   FROM `default`.`transactions`
   

5. Fai clic su OK.

   I metadati per la query vengono recuperati da Hive.

6. Fai clic su Aggiorna ora.

   Tableau recupera i dati da Hive perché sara è autorizzato a leggere queste due colonne dalla tabella transactions.

   

7. Per provare a selezionare tutte le colonne dalla tabella transactions, nel riquadro Tabella, fai di nuovo doppio clic su Nuovo SQL personalizzato. Viene visualizzata la finestra Modifica SQL personalizzato.

8. Inserisci la seguente query:

   SELECT *
   FROM `default`.`transactions`
   

9. Fai clic su Ok. Viene visualizzato il seguente messaggio di errore:

   Permission denied: user [sara] does not have [SELECT] privilege on [default/transactions/*].

   Poiché sara non dispone dell'autorizzazione del ranger per leggere la colonna transactionAmount, è previsto questo messaggio. Questo esempio mostra come limitare i dati a cui gli utenti di Tableau possono accedere.

   Per visualizzare tutte le colonne, ripeti i passaggi utilizzando l'utente admin.

10. Chiudi Tableau e la finestra del terminale.