Protezione del traffico in entrata di Cloud Run

1. Panoramica

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

5aed47d10595c878.png

Impostazioni Ingress

Le impostazioni in entrata ti consentono di filtrare le richieste in base alla loro origine di rete (interna o esterna). Per impostazione predefinita, è consentito passare tutte le richieste, comprese quelle provenienti dalla rete internet pubblica.

Criterio IAM

I criteri IAM consentono di filtrare le richieste in base all'identità del mittente e sono comunemente utilizzati per autenticare le richieste da servizio a servizio.

In questo lab scoprirai come e quando utilizzare le impostazioni di traffico in entrata.

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.

31611f6a2f12fd0c.png

Simulazione di un carico di lavoro 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.

aebf22740c7a84f0.png

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 carico di lavoro on-premise.

2. Configurazione e requisiti

Configurazione dell'ambiente autogestito

  1. 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.

b35bf95b8bf3d5d8.png

a99b7ace416376c4.png

bd84a6d3004737c5.png

  • Il Nome progetto è il nome visualizzato dei partecipanti del progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi aggiornarla in qualsiasi momento.
  • L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca; di solito non ti importa cosa sia. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere è identificato come PROJECT_ID). Se l'ID generato non ti soddisfa, puoi generarne un altro casuale. In alternativa, puoi provarne una personalizzata per verificare se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà per tutta la durata del progetto.
  • Per informazione, c'è un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
  1. Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare risorse/API Cloud. Eseguire questo codelab non dovrebbe costare molto. Per arrestare le risorse in modo da non incorrere in fatturazione oltre questo tutorial, puoi eliminare le risorse che hai creato o eliminare l'intero progetto. I nuovi utenti di Google Cloud sono idonei al programma prova senza costi di 300$.

Configurazione dell'ambiente

  1. 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
  1. Abilita le API richieste per eseguire questo lab.
gcloud services enable \
  run.googleapis.com \
  cloudbuild.googleapis.com \
  compute.googleapis.com \
  artifactregistry.googleapis.com
  1. 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
  1. 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

Devi prima eseguire il deployment del servizio, che poi lascerai accessibile pubblicamente. Dopo che avrai verificato che puoi inviare richieste dal browser, bloccheremo il servizio e consentiremo solo le richieste da fonti di rete interne.

Quando esegui questo comando, 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
  • Consentire chiamate non autenticate a [partner-Registration-service] (y/N)? Y
gcloud run deploy 

Al termine, il comando elenca l'URL del tuo 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 lo rende perfetto per il nostro caso d'uso.

Inoltre, le richieste provenienti da altri prodotti Google Cloud sono considerate interne, anche se non fanno parte del VPC. Tra questi prodotti sono inclusi, ad esempio, Pub/Sub e Workflows.

Le richieste provenienti da queste origini rimangono nella 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, verrà visualizzato il messaggio "Errore: accesso negato: accesso vietato".

Poiché il browser invia la richiesta da un'origine di rete esterna e non da un'origine interna al progetto Google Cloud, è esattamente quello che ti aspetti che avvenga. Ora il tuo servizio è 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 attraverso 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 a questo:

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 seguente comando ti chiede di configurare SSH in Cloud Shell, segui le istruzioni:

gcloud compute ssh jump-server

Utilizza questo comando per recuperare l'URL del servizio Cloud Run:

gcloud run services describe partner-registration-service --region us-central1

Le prime righe dell'output dovrebbero avere il seguente aspetto:

✔ 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 andare a buon fine, perché l'istanza VM viene eseguita nella rete VPC del progetto, che è un'origine interna.

export SERVICE_URL=https://

curl ${SERVICE_URL}

Dovrebbe essere visualizzato il seguente output:

Partner registration service: RUNNING

5. Informazioni sul controllo degli accessi basato su IAM

Questo lab ti ha mostrato come e quando utilizzare le impostazioni di traffico in entrata. Le impostazioni di Ingress sono un ottimo primo passo se colleghi un carico di lavoro on-premise a Cloud Run.

L'implementazione del controllo degli accessi basato su IAM richiede un impegno maggiore, soprattutto se chiami da un host on-premise:

  • IAM richiede la gestione delle credenziali degli account di servizio di lunga durata sull'host
  • IAM richiede modifiche al codice per firmare le richieste utilizzando le credenziali dell'account di servizio.

Google consiglia un approccio a più livelli per il controllo dell'accesso. Utilizzare le impostazioni di traffico in entrata per limitare l'accesso solo agli host interni è un ottimo primo passo, ma non fermarti qui.

6. Complimenti!

Complimenti, hai completato il codelab.

Passaggi successivi

Esplora altri codelab di Cymbal Eats:

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 è quello di eliminare il progetto che hai creato per il tutorial.

Riferimenti utili

Di seguito sono riportate risorse aggiuntive che ti aiutano a saperne di più sui due livelli di controllo dell'accesso in Cloud Run.