1. Panoramica
Questo lab mostra come limitare l'accesso a un servizio Cloud Run e consentire solo le richieste provenienti da un carico di lavoro in esecuzione on-premise o nel VPC del tuo progetto. Puoi utilizzare due livelli di controllo dell'accesso: le impostazioni di ingresso e le policy IAM (Identity and Access Management).

Impostazioni traffico in entrata
Le impostazioni di ingresso ti consentono di filtrare le richieste in base alla loro origine di rete (interna o esterna). Per impostazione predefinita, tutte le richieste possono passare, incluse quelle provenienti da internet pubblico.
Policy IAM
I criteri IAM consentono di filtrare le richieste in base all'identità del mittente e vengono comunemente utilizzati per autenticare le richieste service-to-service.
In questo lab imparerai come e quando utilizzare le impostazioni di ingresso.
Gli host on-premise si connettono tramite il VPC
In questo lab simuleremo un carico di lavoro on-premise. Per connettere un host on-premise a Cloud Run, devi configurare l' accesso privato Google per gli host on-premise. Ciò include la configurazione di un gateway Cloud VPN nella rete VPC, come mostrato di seguito.

Simulazione di un workload on-premise utilizzando un jump server nel VPC
In questo lab simulerai l'invio di richieste da un host on-premise inviando richieste da una macchina virtuale Compute Engine nel VPC, come mostrato qui.

La macchina virtuale Compute Engine che utilizzerai come jump server ha la stessa origine di rete del gateway Cloud VPN, motivo per cui puoi utilizzarla per simulare l'invio di richieste da un workload on-premise.
2. Configurazione e requisiti
Configurazione dell'ambiente autonomo
- Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.



- Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È una stringa di caratteri non utilizzata dalle API di Google. Puoi aggiornarlo in qualsiasi momento.
- L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo l'impostazione). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, devi fare riferimento all'ID progetto (in genere è identificato come
PROJECT_ID). Se non ti piace l'ID generato, puoi generarne un altro casuale. In alternativa, puoi provare a crearne uno e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà per tutta la durata del progetto. - Per tua informazione, esiste un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
- Successivamente, devi abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. L'esecuzione di questo codelab non dovrebbe costare molto, se non nulla. Per arrestare le risorse in modo da non incorrere in costi di fatturazione al termine di questo tutorial, puoi eliminare le risorse che hai creato o l'intero progetto. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.
Configurazione dell'ambiente
- Imposta una variabile di ambiente sull'ID progetto da utilizzare nei comandi successivi:
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export ZONE=us-central1-a
- Abilita le API richieste per eseguire questo lab.
gcloud services enable \
run.googleapis.com \
cloudbuild.googleapis.com \
compute.googleapis.com \
artifactregistry.googleapis.com
- Clona il repository dell'app di esempio e vai alla directory
git clone https://github.com/GoogleCloudPlatform/cymbal-eats.git
cd cymbal-eats/partner-registration-service
- Imposta la regione e la zona predefinite per Compute Engine e Cloud Run
gcloud config set compute/region ${REGION}
gcloud config set run/region ${REGION}
gcloud config set compute/zone ${ZONE}
3. Esegui il deployment del servizio
Per prima cosa, devi eseguire il deployment del servizio e lasciarlo accessibile pubblicamente. Dopo aver verificato che puoi inviare richieste dal browser, bloccheremo il servizio e consentiremo solo le richieste provenienti da fonti di rete interne.
Quando esegui il comando seguente, segui queste istruzioni:
- Posizione del codice sorgente (...): verifica di trovarti nella directory partner-registration-service e premi Invio per accettare il valore predefinito
- Nome servizio (partner-registration-service): premi Invio per accettare il valore predefinito
- Consenti chiamate non autenticate a [partner-registration-service] (y/N)? Y
gcloud run deploy
Al termine del comando, viene visualizzato l'URL del servizio Cloud Run. L'output sarà simile a questo elenco:
Service [partner-registration-service] revision [partner-registration-service-00001-haz] has been deployed and is serving 100 percent of traffic. Service URL: https://partner-registration-service-ssssssssss-uc.a.run.app
Apri l'URL del servizio nel browser. Dovresti vedere questo output:
Partner registration service: RUNNING
Imposta il servizio in modo che consenta solo le richieste interne
Ora utilizzerai le impostazioni di traffico in entrata del servizio Cloud Run per consentire solo le richieste provenienti da origini interne. Le origini interne includono risorse nelle reti VPC che si trovano nello stesso progetto (o perimetro dei Controlli di servizio VPC) del servizio Cloud Run, il che le rende perfette per il nostro caso d'uso.
Inoltre, le richieste di altri prodotti Google Cloud sono considerate interne, anche se non fanno parte del VPC. Questi prodotti includono, ad esempio, Pub/Sub e Workflows.
Le richieste provenienti da queste origini rimangono all'interno della rete Google, anche se accedono al tuo servizio all'URL run.app, e l'accesso pubblico è vietato.
Aggiorna il servizio per consentire solo le richieste interne:
gcloud run services update partner-registration-service --ingress=internal
Se apri di nuovo l'URL del servizio, viene visualizzato il messaggio "Errore: accesso negato".
Poiché il browser invia la richiesta da un'origine di rete esterna e non da un'origine interna al progetto Google Cloud, questo è esattamente ciò che ti aspetti che accada. Il tuo servizio è ora più sicuro.
4. Crea una macchina virtuale Compute Engine come jump server
Il passaggio successivo consiste nel simulare le richieste da un server on-premise tramite un gateway Cloud VPN creando un'istanza Compute Engine nel VPC da utilizzare come jump server:
gcloud compute instances create jump-server --scopes=https://www.googleapis.com/auth/cloud-platform
L'output di questo comando dovrebbe essere simile al seguente:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS jump-server us-central1-a n1-standard-1 10.128.0.10 34.170.108.8 RUNNING
Invia una richiesta dall'istanza Compute Engine al servizio
Ora aprirai un terminale sulla macchina virtuale e invierai una richiesta direttamente dalla macchina nella rete VPC.
Se il comando seguente ti chiede di configurare SSH in Cloud Shell, segui le istruzioni:
gcloud compute ssh jump-server
Recupera l'URL del servizio Cloud Run con questo comando:
gcloud run services describe partner-registration-service --region us-central1
Le prime righe dell'output dovrebbero essere simili a queste:
✔ Service partner-registration-service in region us-central1 URL: https://partner-registration-service-ssssssssss-uc.a.run.app Ingress: internal
Ora copia l'URL e invia una richiesta dall'istanza Compute Engine utilizzando curl. Questa richiesta dovrebbe riuscire perché l'istanza VM viene eseguita nella rete VPC del tuo progetto, quindi è una sorgente interna.
export SERVICE_URL=https://
curl ${SERVICE_URL}
L'output dovrebbe essere:
Partner registration service: RUNNING
5. Che dire del controllo dell'accesso basato su IAM?
Questo lab ha mostrato come e quando utilizzare le impostazioni di ingresso. Le impostazioni Ingress sono un ottimo primo passo se colleghi un carico di lavoro on-premise a Cloud Run.
Il controllo dell'accesso basato su IAM richiede più impegno per l'implementazione, soprattutto se chiami da un host on-premise:
- IAM richiede di gestire le credenziali del service account a lunga durata sull'host
- IAM richiede modifiche al codice per firmare le richieste utilizzando le credenziali del service account.
Google consiglia un approccio multilivello al controllo dell'accesso. L'utilizzo delle impostazioni del traffico in entrata per limitare l'accesso solo agli host interni è un ottimo primo passo, ma non fermarti qui.
6. Complimenti!
Congratulazioni, hai completato il codelab.
Qual è il passaggio successivo?
Esplora altri codelab di Cymbal Eats:
- Attivazione di Cloud Workflows con Eventarc
- Attivazione dell'elaborazione degli eventi da Cloud Storage
- Connessione a Private CloudSQL da Cloud Run
- Connessione a database completamente gestiti da Cloud Run
- Proteggi l'applicazione serverless con Identity-Aware Proxy (IAP)
- Attivazione di Cloud Run Jobs con Cloud Scheduler
- Eseguire il deployment in Cloud Run in modo sicuro
- Connessione ad AlloyDB privato da GKE Autopilot
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
Il modo più semplice per eliminare la fatturazione è eliminare il progetto creato per il tutorial.
Riferimenti utili
Ecco altre risorse che ti aiutano a scoprire di più sui due livelli di controllo dell'accesso su Cloud Run.