Connessione del software di visualizzazione a Hadoop su Google Cloud

Last reviewed 2024-04-17 UTC

Questo tutorial è la seconda parte di una serie che mostra come creare una soluzione end-to-end per fornire agli analisti di dati l'accesso sicuro ai dati quando utilizzano gli strumenti di business intelligence (BI).

Questo tutorial è rivolto a operatori e amministratori IT che configurano ambienti che forniscono funzionalità di elaborazione e dati agli strumenti di business intelligence (BI) utilizzati dagli analisti di dati.

Tableau viene utilizzato come strumento di BI in questo tutorial. Per seguire questo tutorial, devi avere installato Tableau Desktop sulla tua workstation.

La serie è composta dai seguenti componenti:

  • La prima parte della serie, Architettura per la connessione del software di visualizzazione a Hadoop su Google Cloud, definisce l'architettura della soluzione, i suoi componenti e il modo in cui interagiscono.
  • Questa seconda parte della serie spiega come configurare i componenti dell'architettura che costituiscono la topologia Hive end-to-end su Google Cloud. Il tutorial utilizza strumenti open source dell'ecosistema Hadoop, con Tableau come strumento di BI.

Gli snippet di codice in questo tutorial sono disponibili in un repository GitHub. Il repository GitHub include anche file di configurazione Terraform per aiutarti a configurare un prototipo funzionante.

Durante il tutorial, utilizzerai il nome sara come identità utente fittizia di un analista dei dati. Questa identità utente si trova nella directory LDAP utilizzata sia da Apache Knox che da Apache Ranger. Puoi anche scegliere di configurare i gruppi LDAP, ma questa procedura rientra al di fuori dell'ambito di questo tutorial.

Obiettivi

  • Crea una configurazione end-to-end che consenta a uno strumento di BI di utilizzare i dati di un ambiente Hadoop.
  • Autentica e autorizza le richieste degli utenti.
  • Configura e utilizza canali di comunicazione sicuri tra lo strumento di BI e il cluster.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi Google Cloud utenti potrebbero avere diritto a una prova gratuita.

Prima di iniziare

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the Dataproc, Cloud SQL, and Cloud Key Management Service (Cloud KMS) APIs.

    Enable the APIs

Inizializzazione dell'ambiente

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

  2. In Cloud Shell, imposta le variabili di ambiente con l'ID progetto, 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 mantieni la coerenza 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 seguenti ruoli all'account di servizio:

    • Dataproc Worker: per creare e gestire i cluster Dataproc.
    • Cloud SQL Editor: per consentire a Ranger di connettersi al proprio database utilizzando Proxy Cloud SQL.
    • Cloud KMS CryptoKey Decrypter: 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, crei il cluster di backend in cui si trova Ranger. Inoltre, crei il database Ranger per archiviare le regole dei criteri e una tabella di esempio in Hive per applicare i criteri di Ranger.

Crea l'istanza del database Ranger

  1. Crea un'istanza MySQL per archiviare i criteri 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 situata 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 crei una chiave crittografica per criptare le password di Ranger e MySQL. Per impedire l'esfiltrazione, archivia la chiave di crittografia in Cloud KMS. Per motivi di sicurezza, non puoi visualizzare, estrarre o esportare i bit della chiave.

Utilizzi la chiave di crittografia per criptare le password e scriverle nei file. Carica questi file in un bucket Cloud Storage in modo che siano accessibili al service account 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 misura di sicurezza aggiuntiva, crea file di password separati per ogni servizio. Questa azione riduce al minimo l'area potenzialmente interessata se viene esfiltrata una password.

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

  1. In Cloud Shell, crea un portachiavi Cloud KMS per contenere le tue 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 tua. La password deve essere composta 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 dell'utente 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. Crittografa 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 delle password criptate:

    gcloud storage buckets create gs://${PROJECT_ID}-ranger --location=${REGION}
    
  7. Carica i file delle password criptate nel bucket Cloud Storage:

    gcloud storage cp *.encrypted gs://${PROJECT_ID}-ranger
    

Crea il cluster

In questa sezione crei 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 Ranger di Dataproc.

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

    gcloud storage buckets create gs://${PROJECT_ID}-solr --location=${REGION}
    
  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 comodità, alcune delle variabili impostate in precedenza vengono ripetute in questo comando in modo da poterle modificare in base alle tue esigenze.

    Le nuove variabili contengono:

    • Il nome del cluster di backend.
    • L'URI della chiave crittografica 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 o 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 tre righe finali 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 del comando funzionano come segue:
      • Il parametro --optional-components=SOLR,RANGER attiva Apache Ranger e la relativa dipendenza da Solr.
      • Il parametro --enable-component-gateway consente al gateway dei componenti Dataproc di rendere disponibili le interfacce utente di Ranger e di altri componenti Hadoop direttamente dalla pagina del cluster nella console Google Cloud. Quando impostate questo parametro, non è necessario il tunnel SSH al nodo master di backend.
      • Il parametro --scopes=default,sql-admin autorizza Apache Ranger ad accedere al proprio database Cloud SQL.

Se devi creare un metastore Hive esterno che persista oltre il ciclo di vita di qualsiasi cluster e possa essere utilizzato su più cluster, consulta Utilizzare Apache Hive su Dataproc. Per eseguire la procedura, devi eseguire gli esempi di creazione della tabella direttamente su Beeline. Sebbene i comandi gcloud dataproc jobs submit hive utilizzino il trasporto binario di Hive, non sono compatibili con HiveServer2 quando è 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:

    gcloud buckets create gs://${PROJECT_ID}-hive --location=${REGION}
    
  2. Copia un file Parquet di esempio disponibile pubblicamente nel tuo bucket:

    gcloud storage cp gs://hive-solution/part-00000.parquet \
      gs://${PROJECT_ID}-hive/dataset/transactions/part-00000.parquet
    
  3. Connettiti al nodo principale del cluster di backend creato nella sezione precedente tramite 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 HA hanno un sufisso aggiuntivo.

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

  4. Nel terminale aperto con SSH, connettiti a HiveServer2 locale utilizzando Apache Beeline, preinstallato sul nodo principale:

    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 Beeline e passa il nome del progetto Google Cloud in una variabile di ambiente.

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

  5. Nel prompt Beeline, crea una tabella utilizzando il file Parquet che hai copiato in precedenza 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 Beeline:

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

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

    Utilizza questo nome nella sezione successiva come backend-master-internal-dns-name per configurare la topologia di Apache Knox. Utilizzi il nome anche per configurare un servizio in Ranger.

  9. Esci dal terminale sul nodo:

    exit
    

Creazione del cluster proxy

In questa sezione, crei il cluster proxy con l'azione di inizializzazione di Apache Knox.

Creare una topologia

  1. In Cloud Shell, clona il repository GitHub initialization-actions 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, modifica il nome in modo che rappresenti una topologia denominata hive-us-transactions. A questo punto puoi accedere ai dati delle transazioni fittizie caricati in Hive in Creare una tabella Hive di esempio.

  3. Modifica il file di topologia:

    vi hive-us-transactions.xml
    

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

  4. Aggiungi l'identità utente LDAP di esempio dell'analista dei dati 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 DNS interno del cluster di backend acquisito in Creare una tabella Hive di esempio.

  7. Salva il file e chiudi l'editor.

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

In Creare il cluster proxy, copia questi file in un bucket Cloud Storage. Per creare nuove topologie o modificarle dopo aver creato il cluster proxy, modifica i file e caricali di nuovo nel bucket. L'azione di inizializzazione di Apache Knox crea un job cron 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 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 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 il file master_key che cripta i certificati utilizzati dagli strumenti di BI per comunicare con il cluster di proxy. Per impostazione predefinita, questa chiave è la parola secret.

  3. Se fornisci 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:

    gcloud storage buckets create gs://${PROJECT_ID}-knox --location=${REGION}
    

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

  2. Copia tutti i file dalla cartella dell'azione di inizializzazione di Apache Knox nel bucket:

    gcloud storage cp ${KNOX_INIT_FOLDER}/* gs://${PROJECT_ID}-knox --recursive
    
  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
    

Verificare la connessione tramite proxy

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

    gcloud compute ssh --zone ${ZONE} ${PROXY_CLUSTER}-m
    
  2. Dal terminale del nodo master del cluster proxy, esegui la seguente query:

    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 DNS perché il certificato generato durante la configurazione di Apache Knox specifica localhost come nome host. Se utilizzi il tuo nome DNS o il tuo certificato, utilizza il nome host corrispondente.
  • La porta è 8443, che corrisponde alla porta SSL predefinita di Apache Knox.
  • La riga che inizia con ssl=true attiva SSL e fornisce il percorso e la password per l'archivio attendibilità SSL da utilizzare 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 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 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 configurerai le credenziali e i criteri di autorizzazione per questo utente.

Aggiungere 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 contro un data store LDAP ApacheDS. In questa sezione aggiungi un'identità utente sara di analista dei dati di esempio al negozio di autenticazione.

  1. Dal terminale nel nodo principale del proxy, installa le utility 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 daldapadd 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 sia nello store di 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
    

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

  6. Esci dal terminale sul nodo:

    exit
    

Configurazione dell'autorizzazione

In questa sezione, configuri la sincronizzazione delle identità tra il servizio LDAP e Ranger.

Sincronizzare le identità utente in Ranger

Per assicurarti che i criteri di Ranger vengano applicati alle stesse identità utente di Apache Knox, configura il demone Ranger UserSync per sincronizzare le identità dalla stessa directory.

In questo esempio, ti colleghi 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 AD federato.

  1. Utilizzando SSH, connettiti al nodo principale 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 DNS interno del server proxy, che hai recuperato nell'ultima sezione.

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

  4. Salva il file e chiudi l'editor.

  5. Riavvia il demone 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'utentesara.

Creazione di criteri Ranger

In questa sezione, configurerai un nuovo servizio Hive in Ranger. Inoltre, hai configurato e testato un criterio Ranger per limitare l'accesso ai dati di Hive per un'identità specifica.

Configura il servizio Ranger

  1. Dal terminale del nodo principale, 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 HiveServer2 Admin:

    sudo service hive-server2 restart
    

    Ora puoi creare i criteri 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 e poi su Interfacce web.

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

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

  4. Accedi a Ranger con l'utente admin e la password di amministratore di Ranger. La console Ranger mostra la pagina Service Manager con un elenco di servizi.

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

    Ranger Service Manager.

  6. Nel modulo, imposta i seguenti valori:

    • Nome 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 predefinitoorg.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 del plug-in Ranger supporta un singolo servizio Hive. Un modo semplice per configurare servizi Hive aggiuntivi è avviare altri cluster di backend. Ogni cluster ha il proprio plug-in Ranger. Questi cluster possono condividere lo stesso database Ranger, in modo da avere una visione unificata di tutti i servizi ogni volta che accedi alla Console di amministrazione di Ranger da uno di questi cluster.

Configurare un criterio 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 Service Manager, fai clic sul nome del servizio che hai creato.

    Nella Console di amministrazione di Ranger viene visualizzata la finestra Norme.

  2. Fai clic su Aggiungi nuova norma.

    Con questo criterio, concedi a sara l'autorizzazione per visualizzare solo le colonne submissionDate e transactionType dalle 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
    • Consenti condizioni:
      • Seleziona utente: sara
      • Autorizzazioni: select
  4. Nella parte inferiore dello schermo, fai clic su Aggiungi.

Testa il criterio con Beeline

  1. Nel terminale del nodo principale, 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"
    

    Sebbene lo strumento a riga di comando Beeline non imponga la password, devi fornire una password per eseguire il comando precedente.

  2. Esegui la seguente query 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 Permission denied.

  3. Verifica che Ranger consenta la seguente query:

    SELECT submissionDate, transactionType
      FROM transactions
      LIMIT 10;
    
  4. Esci dallo strumento a riga di comando Beeline:

    !quit
    
  5. Esci dal terminale:

    exit
    
  6. Nella console Ranger, fai clic sulla scheda Controllo. Vengono visualizzati sia gli eventi rifiutati sia quelli consentiti. Puoi filtrare gli eventi in base al nome del servizio che hai definito in precedenza, ad esempio ranger-hive-service-01.

    La scheda Controllo Ranger.

Connessione da uno strumento BI

Il passaggio finale di questo tutorial consiste nell'eseguire query sui dati di 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 l'ingresso dalla tua 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 della regola del 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 utilizzi il tuo certificato o il tuo nodo master proxy ha un proprio nome DNS esterno, puoi andare a Connettiti 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 tua workstation.

  4. Crea un tunnel SSH per inoltrare la porta 8443. Copia il comando generato nel primo passaggio, incollalo nel terminale della workstation ed eseguilo.

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

Connettiti a Hive

  1. Sulla workstation, installa il driver ODBC Hive.
  2. Apri Tableau Desktop o riavvialo se era aperto.
  3. Nella home page, seleziona Altro in Connetti / A un server.
  4. Cerca e seleziona Cloudera Hadoop.
  5. Utilizzando l'utente LDAP di analista dei dati di esempio sara come identità utente, 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 tuo nodo master proxy.
    • Porta: 8443
    • Tipo: HiveServer2
    • Autenticazione: Username e Password
    • Nome utente: sara
    • Password: sara-password
    • Percorso HTTP: gateway/hive-us-transactions/hive
    • È richiesto SSL: yes
  6. Fai clic su Accedi.

    Esempi di campi con informazioni per l&#39;input SARA.

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 Table (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 della 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.

    Query di Tableau di esempio con due colonne della tabella &quot;transactions&quot; visualizzate.

  7. Per provare a selezionare tutte le colonne della 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 di Ranger per leggere la colonna transactionAmount, questo messaggio è previsto. Questo esempio mostra come limitare i dati a cui possono accedere gli utenti di Tableau.

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

  10. Chiudi Tableau e la finestra del terminale.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina il progetto

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi