Accedere a un'istanza di Looker (Google Cloud core) utilizzando l'accesso ai servizi privati

Questa pagina della documentazione descrive come configurare un dominio personalizzato e l'accesso a un'istanza di Looker (Google Cloud core) che soddisfi i seguenti criteri:

Per accedere a questo tipo di istanza, segui questi passaggi:

  1. Configura il dominio personalizzato.
  2. Crea VM e una zona privata.
  3. Configura i server proxy inverso.
  4. Crea e configura il bilanciatore del carico.
  5. Crea regole firewall.
  6. Aggiorna il record A DNS.
  7. Aggiorna le credenziali OAuth.

Configurazione di un dominio personalizzato

Una volta creata l'istanza di Looker (Google Cloud core), puoi configurare un dominio personalizzato.

Prima di iniziare

Prima di poter personalizzare il dominio dell'istanza di Looker (Google Cloud core), identifica dove sono archiviati i record DNS del tuo dominio, in modo da poterli aggiornare.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per creare un dominio personalizzato per un'istanza di Looker (Google Cloud core), chiedi all'amministratore di concederti il ruolo IAM Amministratore di Looker (roles/looker.admin) nel progetto in cui si trova l'istanza. Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Creare un dominio personalizzato

Nella console Google Cloud , segui questi passaggi per personalizzare il dominio dell'istanza di Looker (Google Cloud core):

  1. Nella pagina Istanze, fai clic sul nome dell'istanza per cui vuoi configurare un dominio personalizzato.
  2. Fai clic sulla scheda DOMINIO PERSONALIZZATO.

  3. Fai clic su AGGIUNGI UN DOMINIO PERSONALIZZATO.

    Si aprirà il riquadro Aggiungi un nuovo dominio personalizzato.

  4. Utilizzando solo lettere, numeri e trattini, inserisci il nome host di un massimo di 64 caratteri per il dominio web che vuoi utilizzare, ad esempio: looker.examplepetstore.com.

  5. Fai clic su FINE nel riquadro Aggiungi un nuovo dominio personalizzato per tornare alla scheda DOMINIO PERSONALIZZATO.

Una volta configurato, il dominio personalizzato viene visualizzato nella colonna Dominio della scheda DOMINIO PERSONALIZZATO della pagina dei dettagli dell'istanza di Looker (Google Cloud core) nella console Google Cloud .

Una volta creato il dominio personalizzato, puoi visualizzarne le informazioni o eliminarlo.

Accedere al dominio personalizzato

Quando il traffico verso un'istanza di Looker (Google Cloud core) solo con IP privato ha origine da una regione diversa da quella dell'istanza, puoi utilizzare uno o più server reverse proxy con IP privato e un bilanciatore del carico per fornire un accesso sicuro all'istanza.

Prima di iniziare

Per ottenere le autorizzazioni necessarie per configurare l'accesso a un dominio personalizzato con IP privato, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto in cui si trova l'istanza:

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Panoramica sul networking

Le sezioni seguenti mostrano come creare una configurazione di server proxy NGINX o Apache ridondante, con un bilanciatore del carico, per instradare il traffico da qualsiasi regione o da on-premise al dominio personalizzato. Il seguente diagramma rappresenta questa topologia:

Una rete Google Cloud che mostra l'accesso sicuro a un'istanza di Looker (Google Cloud core) utilizzando router Cloud, un bilanciamento del carico interno e Private Services Access.

Crea VM, una zona privata e un record A

Completa i passaggi descritti nelle sezioni seguenti.

Crea VM

Crea due istanze VM solo con IP privato con un sistema operativo RHEL. Le VM fungeranno da server proxy. Devono trovarsi nella stessa regione dell'istanza di Looker (Google Cloud core), ma in zone diverse tra loro.

Creare una zona privata

Crea una zona privata Cloud DNS visibile al VPC in cui si trova l'istanza di Looker (Google Cloud core). La zona privata Cloud DNS verrà utilizzata da VPC e dagli host on-premise per la risoluzione DNS per raggiungere la UI di Looker (Google Cloud core). Il nome della zona deve corrispondere al dominio personalizzato.

  gcloud dns managed-zones create NAME \
  --description=DESCRIPTION \
  --dns-name=DNS_SUFFIX \
  --networks=VPC_NETWORK_LIST \
  --labels=LABELS \
  --visibility=private

Sostituisci quanto segue:

  • NAME: un nome per la zona.
  • DESCRIPTION: una descrizione della zona.

  • DNS_SUFFIX: il suffisso DNS per la zona, ad esempio examplepetstore.com.

  • VPC_NETWORK_LIST: un elenco delimitato da virgole di reti VPC autorizzate a eseguire query sulla zona. Assicurati di includere il VPC che contiene l'istanza di Looker (Google Cloud core).

  • LABELS: un elenco facoltativo di coppie chiave-valore separate da virgole, ad esempio dept=marketing o project=project1; per maggiori informazioni, consulta la documentazione dell'SDK.

Una volta configurata la zona, se vai alla zona nella pagina Zone Cloud DNS della console Google Cloud , puoi vedere che è privata, che prende il nome dal dominio personalizzato e che contiene i set di record per il dominio personalizzato.

Aggiungi il record A di Cloud DNS

Per aggiungere il record A di Cloud DNS, completa i seguenti passaggi:

  1. Poiché utilizzerai un bilanciatore del carico, il record A nella zona privata di Cloud DNS verrà mappato all'indirizzo IP del bilanciatore del carico.

    L'IP privato in entrata evidenziato nella scheda Dettagli della pagina Istanze.

  2. Aggiungi un record A DNS per il dominio personalizzato nella zona privata, costituito dall'indirizzo IP in entrata dell'istanza di Looker (Google Cloud core). Il record A utilizza il nome di dominio completo (FQDN), lo stesso che hai configurato come dominio personalizzato di Looker (Google Cloud core).

    La configurazione completa dovrebbe mostrare il record A per il dominio personalizzato quando visualizzi i dettagli della zona privata nella pagina Zone Cloud DNS della console Google Cloud .

    Per rendere disponibili i servizi di risoluzione dei nomi di una rete VPC alle reti on-premise connesse alla rete VPC utilizzando tunnel Cloud VPN, collegamenti VLAN Cloud Interconnect o appliance router, puoi utilizzare un'policy del server in entrata.

    Una volta aggiornati i record DNS del dominio e verificato il dominio nella console Google Cloud, lo stato del dominio personalizzato mappato all'istanza verrà aggiornato da Non verificato a Disponibile nella scheda Dominio personalizzato della pagina Istanze.

Configura i server proxy inverso

Puoi utilizzare qualsiasi server web che può essere configurato come server proxy inverso. Seleziona una delle seguenti opzioni per visualizzare esempi di configurazione di server proxy inverso utilizzando NGINX o Apache:

NGINX

L'esempio seguente utilizza NGINX versione 1.22.1 e Red Hat Enterprise Linux versione 8.9 (Ootpa). Per verificare le versioni di NGNIX e Red Hat utilizzate dalle tue VM, esegui i seguenti comandi per ogni VM.

  1. Per prima cosa, connettiti alla VM.

  2. Installa NGINX utilizzando il seguente comando:

    sudo yum install nginx -y

  3. Per trovare la versione di NGINX in esecuzione sulla VM, esegui questo comando: 

    sudo nginx -v

    Dovresti ottenere un risultato simile al seguente:

    nginx version: nginx/1.22.1

  4. Per controllare la versione di NGINX in esecuzione sulla VM, esegui questo comando: 

    sudo rpm -qi nginx | grep Release

    Dovresti ottenere un risultato simile al seguente:

    Release : 1.module+el8.8.0+20355+6d9c8a63.1

  5. Per verificare quale versione di Red Hat utilizzano le tue VM, esegui questo comando:

    sudo cat /etc/redhat-release

Per configurare ogni server proxy, utilizza le seguenti istruzioni per ciascuna delle due VM che hai creato.

  1. Connettiti alla VM.

  2. Modifica il file /etc/nginx/nginx.conf in modo che contenga la seguente configurazione:

    events {
  worker_connections 1024;
}

http {
  log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

  log_format debug  '$http_x_forwarded_for - $remote_user [$time_local] '
                    '"$request_method $scheme://$host$request_uri $server_protocol" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" $request_time';

  access_log  /var/log/nginx/access.log  debug;

  sendfile            on;
  tcp_nopush          on;
  keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

server {
  listen 443 ssl;
  # listen [::]:443 ssl;
  include snippets/self-signed.conf;
  # include snippets/ssl-params.conf;
  server_name CUSTOM_DOMAIN;
  location / {
    proxy_pass https://INGRESS_PRIVATE_IP/$request_uri;
    proxy_set_header Host $server_name;
    proxy_http_version 1.1;
  }
}
server {
  listen 80;
  # listen [::]:80;
  server_name CUSTOM_DOMAIN;
  return 302 https://$server_name$request_uri;
  }
}

    Sostituisci quanto segue:

    • CUSTOM_DOMAIN: il dominio personalizzato dell'istanza di Looker (Google Cloud core)
    • INGRESS_PRIVATE_IP: l'IP privato in entrata per l'istanza di Looker (Google Cloud core)

    Inoltre, tieni presente quanto segue:

    • Questa è una configurazione solo IPv4. Se vuoi che il proxy ascolti anche il suo indirizzo IPv6 privato, rimuovi il commento dalla riga listen [::]:443 ssl nel file.
    • Il livello del log di accesso è impostato su debug; assicurati di regolarlo sul livello utilizzato nel tuo ambiente specifico.
    • Se implementi il file ssl-params.conf, a cui viene fatto riferimento più avanti in questi passaggi, rimuovi il commento da include snippets/ssl-params.conf.

  3. Crea un certificato TLS valido che faccia riferimento all'URL del dominio personalizzato di Looker (Google Cloud core). Questo certificato verrà presentato dal proxy ai client che tentano di accedere a Looker (Google Cloud core). L'autorità di certificazione (CA) utilizzata per firmare il certificato deve essere attendibile per i tuoi client. Puoi anche utilizzare una CA privata interna per firmare questo certificato TLS. In alternativa, puoi utilizzare anche un certificato SSL autogestito.

    In questo esempio, supponiamo che il certificato sia già stato creato utilizzando il servizio gratuito Let's Encrypt, senza configurare il rinnovo automatico tramite Certbot. Una volta creato il certificato, salva i file pertinenti nelle directory certs e private su ogni VM proxy:

    /etc/pki/tls/certs/custom-domain.custom-domain.com.fullchain.pem;
/etc/pki/tls/private/custom-domain.custom-domain.com.key.pem;

    Sostituisci custom-domain.custom-domain.com con il tuo dominio personalizzato.

    Se le directory certs e private non esistono nell'installazione, puoi crearle o utilizzare altre cartelle.

  4. Per assicurarti che NGINX rilevi i file dei certificati, crea la directory /etc/nginx/snippets:

    sudo mkdir /etc/nginx/snippets

  5. Crea il file di configurazione, /etc/nginx/snippets/self-signed.conf:

    sudo touch /etc/nginx/snippets/self-signed.conf

    Modifica il file di configurazione per aggiungere i percorsi ai file del certificato che hai salvato:

    ssl_certificate /etc/pki/tls/certs/custom-domain.custom-domain.com.fullchain.pem;
ssl_certificate_key /etc/pki/tls/private/custom-domain.custom-domain.com.key.pem;

    Sostituisci custom-domain.custom-domain.com con il tuo dominio personalizzato.

  6. Per verificare che il file di configurazione contenga il riferimento ai file menzionati nel passaggio precedente, esegui questo comando: 

    sudo more /etc/nginx/snippets/self-signed.conf

    Dovrebbe restituire i percorsi dei file che hai aggiunto.

  7. (Facoltativo) Crea il file ssl-params.conf NGINX, che può essere utilizzato per archiviare parametri riutilizzabili nelle future configurazioni NGINX.

    A titolo di riferimento, i contenuti del file dovrebbero essere simili a quelli riportati di seguito:

    ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_ecdh_curve secp384r1;
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.0.53 valid=300s;
resolver_timeout 5s;
# Disable strict transport security for now. You can uncomment the following
# line if you understand the implications.
#add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

  8. Per configurare SELinux in modo da consentire a NGINX di inoltrare il traffico all'IP di ingresso di Looker (Google Cloud core), imposta il parametro booleano SELinux httpd_can_network_connect su 1:

    sudo setsebool -P httpd_can_network_connect 1

  9. Ora puoi riavviare il processo NGINX utilizzando questo comando:

    sudo systemctl restart nginx

  10. Verifica che NGINX sia stato riavviato correttamente utilizzando questo comando:

    sudo systemctl status nginx

    Dovrebbe restituire un output simile al seguente:

    nginx.service - The nginx HTTP and reverse proxy server
  Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
  Active: active (running) since Tue 2024-05-14 11:58:00 UTC; 9min ago
  Process: 144044 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
  Process: 144042 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
  Process: 144039 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Main PID: 144045 (nginx)
    Tasks: 2 (limit: 11040)
  Memory: 2.6M
  CGroup: /system.slice/nginx.service
          ├─144045 nginx: master process /usr/sbin/nginx
          └─144046 nginx: worker process
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: nginx.service: Succeeded.
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: Stopped The nginx HTTP and reverse proxy server.
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: Starting The nginx HTTP and reverse proxy server...
May 14 11:58:00 proxy-three-eu-w4 nginx[144042]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
May 14 11:58:00 proxy-three-eu-w4 nginx[144042]: nginx: configuration file /etc/nginx/nginx.conf test is successful
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: Started The nginx HTTP and reverse proxy server.

Apache

Completa questi passaggi per ogni VM.

  1. Per prima cosa, connettiti alla VM.

  2. Installa Apache:

    sudo yum install httpd -y

  3. L'esempio seguente utilizza Red Hat Enterprise Linux versione 7.9. Per verificare quali versioni di Red Hat utilizzano le tue VM, esegui questo comando:

    cat /etc/redhat-release

    Dovrebbe essere restituito quanto segue:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. L'esempio seguente utilizza la release 2.4.6 di Apache. Per verificare quali versioni di Apache utilizzano le tue VM, esegui i seguenti comandi per ogni VM:

    sudo httpd -version

    Dovrebbe essere restituito quanto segue:

    Server version: Apache/2.4.6 (Red Hat Enterprise Linux)
Server built:   date

  5. Per ulteriori informazioni sul server Apache, esegui questo comando:

    sudo rpm -qi httpd

    Dovrebbe essere restituito un output simile al seguente:

    Name        : httpd
Version     : 2.4.6
Release     : 99.el7_9.1
Architecture: x86_64
Install Date: Tue May  7 15:48:59 2024
Group       : System Environment/Daemons
Size        : 3899819
License     : ASL 2.0
Signature   : RSA/SHA256, Fri Apr 28 17:09:45 2023, Key ID 199e2f91fd431d51
Source RPM  : httpd-2.4.6-99.el7_9.1.src.rpm
Build Date  : Fri Apr 28 16:56:11 2023
Build Host  : x86-vm-40.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. 
Vendor      : Red Hat, Inc.
URL         : http://httpd.apache.org/
Summary     : Apache HTTP Server
Description :
The Apache HTTP Server is a powerful, efficient, and extensible
web server.

  6. Crea il file di configurazione /etc/httpd/conf.d/ssl.conf sulla VM proxy e aggiungi la seguente configurazione al file:

    ServerName custom domain of Looker (Google Cloud core)
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on
#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3
#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA
#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
# SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateFile "/etc/pki/tls/certs/custom domain of Looker (Google Cloud core).crt"
#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
# SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile "/etc/pki/tls/private/custom domain of Looker (Google Cloud core).key"
SSLProxyEngine On
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
ProxyPreserveHost On
RewriteEngine On
AllowEncodedSlashes NoDecode
ProxyPass / https://private IP of Looker (Google Cloud core)>:443/
RewriteCond %{REQUEST_URI} ^/render/
RewriteRule ^(.*)$ https://private IP of Looker (Google Cloud core)>:443/$1 [P]
RewriteRule ^(.*)$ https://private IP of Looker (Google Cloud core)>:443/$1 [P,NE]
ProxyPassReverse / https://private IP of Looker (Google Cloud core):443/

    Sostituisci quanto segue:

    • custom domain of Looker (Google Cloud core): il dominio personalizzato dell'istanza di Looker (Google Cloud core).
    • private IP of Looker (Google Cloud core): l'IP privato dell'istanza di Looker (Google Cloud core).

  7. Verifica che i file dei certificati TLS siano disponibili nelle directory a cui viene fatto riferimento nel file /etc/httpd/conf.d/ssl.conf:

    SSLCertificateFile "/etc/pki/tls/certs/custom domain of Looker (Google Cloud core).crt"
SSLCertificateKeyFile "/etc/pki/tls/private/custom domain of Looker (Google Cloud core).key"

  8. Controlla se mod_ssl è installato:

    sudo yum list installed | grep mod_ssl

    Se mod_ssl non è installato, installalo con il seguente comando:

    sudo yum install mod_ssl

    Una volta installato mod_ssl, devi abilitarlo aggiungendo la seguente riga al file di configurazione di Apache, /etc/httpd/conf/httpd.conf:

    LoadModule ssl_module modules/mod_ssl.so

  9. Nel file di configurazione di Apache, /etc/httpd/conf/httpd.conf, sostituisci Listen 80 con Listen 443.

  10. Esegui questo comando per consentire alla VM proxy Apache di inoltrare il traffico a Looker (Google Cloud core):

    /usr/sbin/setsebool -P httpd_can_network_connect 1

  11. Infine, riavvia Apache per applicare le modifiche:

    sudo systemctl restart httpd

  12. Verifica che il modulo di riscrittura sia caricato e pronto su Apache utilizzando questo comando:

    sudo httpd -M | grep rewrite

    Dovrebbe restituire un output simile al seguente:

    rewrite_module (shared)

  13. Infine, avvia o riavvia il processo Apache per assicurarti che tutte le modifiche alla configurazione vengano rilevate:

    sudo systemctl restart httpd

  14. Verifica che il processo Apache sia stato riavviato correttamente utilizzando il comando seguente: 

    sudo systemctl status httpd

    Dovrebbe restituire un output simile al seguente:

    httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2024-05-14 15:41:57 UTC; 1s ago
  Docs: man:httpd(8)
        man:apachectl(8)
Main PID: 1400 (httpd)
Status: "Processing requests..."
CGroup: /system.slice/httpd.service
        ├─1400 /usr/sbin/httpd -DFOREGROUND
        ├─1401 /usr/sbin/httpd -DFOREGROUND
        ├─1402 /usr/sbin/httpd -DFOREGROUND
        ├─1403 /usr/sbin/httpd -DFOREGROUND
        ├─1404 /usr/sbin/httpd -DFOREGROUND
        └─1405 /usr/sbin/httpd -DFOREGROUND
May 14 15:41:57 proxy-ingress-apache systemd[1]: Starting The Apache HTTP Server...
May 14 15:41:57 proxy-ingress-apache systemd[1]: Started The Apache HTTP Server.

Crea e configura il bilanciatore del carico

Questi esempi utilizzano gruppi di endpoint di rete (NEG) di zona con GCE_VM_IP endpoint come backend del bilanciatore del carico di rete passthrough interno. Se preferisci utilizzare i backend basati su gruppi di istanze, segui la documentazione disponibile nella pagina Configura un bilanciatore del carico di rete passthrough interno con backend di gruppi di istanze VM.

  1. Crea un NEG zonale separato per ogni zona di computing in cui prevedi di eseguire il deployment dei server proxy. Ad esempio, se vuoi eseguire il deployment di server proxy in ciascuna delle tre zone di calcolo della regione in cui è stato eseguito il deployment di Looker (Google Cloud core), crea tre NEG zonali. Consulta la pagina di documentazione Quote e limiti per verificare quanti endpoint sono supportati per ogni NEG zonale.

    Per creare un NEG a livello di zona, utilizza il seguente comando gcloud:

    gcloud compute network-endpoint-groups create NEG_NAME --network-endpoint-type=gce-vm-ip \
--zone=PROXY_INSTANCE_ZONE --network=PROXY_INSTANCE_VPC \
--subnet=PROXY_INSTANCE_SUBNET

    Sostituisci quanto segue:

    • NEG_NAME: il nome del NEG che stai creando.
    • PROXY_INSTANCE_ZONE: la zona in cui si trova il server proxy.
    • PROXY_INSTANCE_VPC: il VPC che contiene il server proxy.
    • PROXY_INSTANCE_SUBNET: la subnet in cui si trova il server proxy.

    Ripeti questo passaggio per qualsiasi zona aggiuntiva in cui verrà eseguito il deployment di una VM server proxy.

  2. Aggiungi ogni server proxy al NEG nella stessa zona:

    gcloud compute network-endpoint-groups update NEG_NAME --zone=PROXY_INSTANCE_ZONE \
--add-endpoint='instance=PROXY_INSTANCE_NAME'

    Sostituisci quanto segue:

    • PROXY_INSTANCE_ZONE: la zona in cui si trova il server proxy.
    • NEG_NAME: il nome del NEG nella stessa zona del server proxy.
    • PROXY_INSTANCE_NAME: il nome del server proxy.

    Ripeti questo passaggio finché ogni VM del server proxy non viene aggiunta a un NEG come endpoint.

  3. Crea un controllo di integrità a livello di regione che verrà utilizzato dal bilanciatore del carico interno. Utilizza il comando compute health-checks create:

    gcloud compute health-checks create PROTOCOL NAME \
    --region=REGION \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

    Sostituisci quanto segue:

    • PROTOCOL: il protocollo utilizzato per il controllo di integrità. Le opzioni valide sono grpc, http, https, http2, ssl e tcp.
    • NAME: il nome del controllo di integrità. All'interno di un determinato progetto, ogni controllo di integrità globale deve avere un nome univoco e i controlli di integrità regionali devono avere nomi univoci all'interno di una determinata regione.
    • REGION: tutti i bilanciatori del carico, ad eccezione dei bilanciatori del carico delle applicazioni esterni regionali e dei bilanciatori del carico delle applicazioni interni regionali, utilizzano controlli di integrità globali (--global). I bilanciatori del carico delle applicazioni interni regionali utilizzano controlli di integrità regionali la cui regione deve corrispondere a quella del servizio di backend.
    • DESCRIPTION: una descrizione facoltativa.
    • CHECK_INTERVAL: l'intervallo di tempo dall'inizio della connessione di un probe del sistema di controllo di integrità all'inizio di quella successiva. Le unità sono secondi. Se omesso, Google Cloud utilizza un valore di 5s (5 secondi).
    • TIMEOUT: il tempo di attesa da parte di Google Cloud per una risposta a un probe. Il valore di TIMEOUT deve essere inferiore o uguale a CHECK_INTERVAL. Le unità sono in secondi. Se omesso, Google Cloud utilizza un valore di 5s (5 secondi).
    • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: specifica il numero di probe sequenziali che devono riuscire o non riuscire affinché l'istanza VM sia considerata integra o non integra. Se uno dei due viene omesso, Google Cloud utilizza una soglia predefinita di 2.
    • PORT_SPECIFICATION: definisce la specifica della porta utilizzando uno dei flag di specifica della porta.
    • ADDITIONAL_FLAGS: Altri flag per specificare porte e opzioni specifiche per PROTOCOL. Consulta Flag aggiuntivi per i controlli di integrità HTTP, HTTPS e HTTP/2, Flag aggiuntivi per i controlli di integrità SSL e TCP o Flag aggiuntivo per i controlli di integrità gRPC.

  4. Crea il servizio di backend:

    gcloud compute backend-services create BS_NAME --load-balancing-scheme=INTERNAL \
--protocol=tcp --region=PROXY_INSTANCES_REGION --health-checks=HC_NAME \
--health-checks-region=HC_REGION --session-affinity=CLIENT_IP \
--connection-persistence-on-unhealthy-backends=NEVER_PERSIST

    Sostituisci quanto segue:

    • BS_NAME: il nome del bilanciatore del carico che stai creando.
    • PROXY_INSTANCES_REGION: la regione in cui si trovano i server proxy.
    • HC_NAME: il nome del controllo di integrità a livello di regione che hai creato.
    • HC_REGION: la regione in cui si trova il controllo di integrità.

    Inoltre:

    • Il flag --session-affinity=CLIENT_IP indirizza la richiesta di un determinato client alla stessa VM di istanza proxy di backend, in base a un hash creato sia sull'indirizzo IP del client sia sull'indirizzo di destinazione.
    • Il flag --connection-persistence-on-unhealthy-backends=NEVER_PERSIST indica che le connessioni non verranno mantenute sulle VM delle istanze proxy non integre.

  5. Aggiungi ciascun NEG al servizio di backend:

    gcloud compute backend-services add-backend BS_NAME --region=BS_REGION \
--network-endpoint-group=NEG_NAME --network-endpoint-group-zone=NEG_ZONE

    Sostituisci quanto segue:

    • BS_NAME: il nome del servizio di backend che hai creato.
    • BS_REGION: la regione in cui si trova il servizio di backend, che deve corrispondere a quella in cui si trovano i server proxy.
    • NEG_NAME: il nome del NEG che stai aggiungendo.
    • NEG_ZONE: la zona in cui si trova il NEG.

    Ripeti questo passaggio per l'ulteriore NEG che hai creato.

  6. Prenota un indirizzo IP interno nel VPC all'interno dell'intervallo IP della subnet a cui sono connesse le istanze proxy. Questo sarà l'indirizzo IP virtuale (VIP) del bilanciatore del carico interno. La prenotazione dell'indirizzo garantisce che l'IP non venga utilizzato da altri oggetti. Per prenotare l'indirizzo IP interno, utilizza il comando compute addresses create:

    gcloud compute addresses create ADDRESS_NAMES \
    --region REGION --subnet SUBNETWORK \
    --addresses IP_ADDRESS

    Sostituisci quanto segue:

    • ADDRESS_NAMES: I nomi di uno o più indirizzi [--purpose=SHARED_LOADBALANCER_VIP] che vuoi creare. In caso di più indirizzi, specifica tutti gli indirizzi come elenco, separati da spazi, ad esempio example-address-1 example-address-2 example-address-3
    • REGION: La regione per questa richiesta.
    • SUBNETWORK: la subnet per questo indirizzo IP interno.
    • IP_ADDRESS: l'indirizzo IP da prenotare, che deve rientrare nell'intervallo IP principale della subnet. Se non specificato, un indirizzo IP viene allocato automaticamente dalla subnet.

  7. Crea la regola di forwarding e associala al servizio di backend e al VIP:

    gcloud compute forwarding-rules create FW_RULE_NAME --region=BS_REGION \
--load-balancing-scheme=internal --network=PROXY_INSTANCES_VPC_NAME --subnet=RESERVED_IP_ADDRESS_SUBNET \
--address=RESERVED_IP_ADDRESS --ip-protocol=tcp --ports=ALL --backend-service=BS_NAME \
--backend-service-region=BS_REGION --allow-global-access

    Sostituisci quanto segue:

    • FW_RULE_NAME: il nome della regola di forwarding che stai creando.
    • BS_REGION: la regione in cui si trova il servizio di backend
    • PROXY_INSTANCES_VPC_NAME: il nome del VPC in cui sono state create le VM del server proxy
    • RESERVED_IP_ADDRESS_SUBNET: La subnet in cui si trova il VIP
    • RESERVED_IP_ADDRESS: l'indirizzo VIP del bilanciatore del carico
    • BS_NAME: il nome del servizio di backend

    Inoltre:

    • Il flag --allow-global-access indica che il VIP del bilanciatore del carico è raggiungibile da qualsiasi regione (non solo da BS_REGION). Ciò consente ai client di ogni regione di raggiungere l'istanza di Looker (Google Cloud core).

Crea regole firewall

Affinché i controlli di integrità funzionino, crea regole firewall in entrata applicabili alla VM proxy con bilanciamento del carico per consentire il traffico proveniente dagli intervalli IP di controllo di integrità.

Inoltre, crea una regola firewall in entrata per consentire al traffico dagli ambienti on-premise o multicloud di accedere al servizio di backend del bilanciatore del carico.

Aggiorna il record A DNS

Modifica il record A del dominio personalizzato di Looker (Google Cloud core) in modo che punti al VIP del bilanciatore del carico. La zona privata Cloud DNS che hai creato gestisce il dominio personalizzato e viene utilizzata dal VPC in cui si trovano le istanze proxy.

Aggiorna le credenziali OAuth

  1. Accedi al client OAuth andando nella console Google Cloud a API e servizi > Credenziali e selezionando l'ID client OAuth per il client OAuth utilizzato dall'istanza di Looker (Google Cloud core).

  2. Fai clic sul pulsante Aggiungi URI per aggiornare il campo Origini JavaScript autorizzate nel client OAuth in modo da includere lo stesso nome DNS che la tua organizzazione utilizzerà per accedere a Looker (Google Cloud core). Quindi, se il tuo dominio personalizzato è looker.examplepetstore.com, inserisci looker.examplepetstore.com come URI.

  3. Aggiorna o aggiungi il dominio personalizzato all'elenco degli URI di reindirizzamento autorizzati per le credenziali OAuth che hai utilizzato durante la creazione dell'istanza di Looker (Google Cloud core). Aggiungi /oauth2callback alla fine dell'URI. Quindi, se il tuo dominio personalizzato è looker.examplepetstore.com, inserisci looker.examplepetstore.com/oauth2callback.

Aggiunta di utenti

Una volta completati i passaggi precedenti, l'URL del dominio personalizzato è accessibile agli utenti.

Assicurati che il metodo di autenticazione utente sia completamente configurato per l'istanza di Looker (Google Cloud core) prima di aggiungere utenti all'istanza.

Risoluzione dei problemi

  • Se utilizzi Chrome per accedere al dominio personalizzato di Looker (Google Cloud core) e ricevi un errore di Chrome come NET::ERR_CERT_COMMON_NAME_INVALID o un errore relativo al criterio HSTS, puoi risolverlo seguendo questi passaggi:

    1. Apri chrome://net-internals/#hsts
    2. Inserisci il dominio personalizzato per eseguire una query sul set HSTS/PKP. Le norme per il dominio personalizzato verranno visualizzate nella sezione Trovate.
    3. In Elimina criteri di sicurezza del dominio, inserisci il dominio personalizzato nel campo Dominio.
    4. Fai clic su Elimina per eliminare i criteri.

  • Per risolvere i problemi relativi ai certificati, consulta la pagina di documentazione Risoluzione dei problemi relativi ai certificati SSL. Per i certificati gestiti da Google, assicurati di autorizzare esplicitamente l'autorità di certificazione che vuoi autorizzare a emettere il certificato gestito da Google.

Passaggi successivi