Se la tua architettura utilizza più servizi, è probabile che questi servizi debbano comunicare tra loro, utilizzando mezzi asincroni o sincroni. Molti di questi servizi potrebbero essere privati e quindi richiedere credenziali per l'accesso.
Per la comunicazione asincrona, puoi utilizzare i seguenti Google Cloud servizi:
- Cloud Tasks per la comunicazione asincrona uno a uno
- Pub/Sub per la comunicazione asincrona uno a molti, uno a uno e molti a uno
- Cloud Scheduler per la comunicazione asincrona pianificata regolarmente
- Eventarc per la comunicazione basata su eventi
In tutti questi casi, il servizio utilizzato gestisce l'interazione con il servizio ricevente, in base alla configurazione impostata.
Tuttavia, per la comunicazione sincrona, il servizio chiama direttamente un altro servizio tramite HTTP, utilizzando l'URL dell'endpoint. Per questo caso d'uso, devi assicurarti che ogni servizio sia in grado di effettuare richieste solo a servizi specifici. Ad esempio, se hai un servizio login, questo deve essere in grado di accedere al servizio user-profiles, ma non al servizio search.
In questa situazione, Google consiglia di utilizzare IAM e un'identità di servizio basata su un service account gestito dall'utente per ogni servizio a cui è stato concesso il set minimo di autorizzazioni necessarie per svolgere il proprio lavoro.
Inoltre, la richiesta deve presentare una prova dell'identità del servizio chiamante. Per farlo, configura il servizio chiamante in modo che aggiunga un token ID OpenID Connect firmato da Google come parte della richiesta.
Configurare il account di servizio
Per configurare un account di servizio, configura il servizio ricevente in modo che accetti le richieste del servizio chiamante rendendo il account di servizio del servizio chiamante un' entità sul servizio ricevente. Poi concedi a questo account di servizio il ruolo Cloud Run Invoker (roles/run.invoker). Per eseguire entrambe queste attività, segui le istruzioni nella scheda appropriata:
Interfaccia utente della console
Vai alla Google Cloud console:
Seleziona il servizio ricevente.
Fai clic su Mostra riquadro Informazioni nell'angolo in alto a destra per visualizzare la scheda Autorizzazioni.
Fai clic su Aggiungi entità.
Inserisci l'identità del servizio chiamante. In genere si tratta di un indirizzo email, per impostazione predefinita
PROJECT_NUMBER-compute@developer.gserviceaccount.com.Seleziona il ruolo
Cloud Run Invokerdal menu a discesa Seleziona un ruolo.Fai clic su Salva.
gcloud
Utilizza il comando gcloud run services add-iam-policy-binding:
gcloud run services add-iam-policy-binding RECEIVING_SERVICE \ --member='serviceAccount:CALLING_SERVICE_IDENTITY' \ --role='roles/run.invoker'
dove RECEIVING_SERVICE è il nome del servizio ricevente e CALLING_SERVICE_IDENTITY è l'indirizzo email del account di servizio, per impostazione predefinita PROJECT_NUMBER-compute@developer.gserviceaccount.com.
Terraform
Per scoprire come applicare o rimuovere una configurazione Terraform, consulta Comandi Terraform di base.
Aggiungi quanto segue a unagoogle_cloud_run_v2_service
risorsa nella configurazione Terraform:Sostituisci us-docker.pkg.dev/cloudrun/container/hello con un riferimento all'immagine container.
Il seguente codice Terraform rende pubblico il servizio iniziale.
Il seguente codice Terraform crea un secondo servizio Cloud Run destinato a essere privato.
Sostituisci us-docker.pkg.dev/cloudrun/container/hello con un riferimento all'immagine container.
Il seguente codice Terraform rende privato il secondo servizio.
Il seguente codice Terraform crea un account di servizio.
Il seguente codice Terraform consente ai servizi collegati al account di servizio di richiamare il servizio Cloud Run privato iniziale.
Acquisire e configurare il token ID
Dopo aver concesso il ruolo appropriato al account di servizio chiamante, segui questi passaggi:
Recupera un token ID firmato da Google utilizzando uno dei metodi descritti nella sezione seguente. Imposta l'attestazione del pubblico (
.aud) sull'URL del servizio ricevente o su un segmento di pubblico personalizzato configurato. Se non utilizzi un segmento di pubblico personalizzato, il valoreauddeve rimanere l' URL del servizio, anche quando effettui richieste a un tag di traffico specifico.Aggiungi il token ID recuperato nel passaggio precedente a una delle seguenti intestazioni nella richiesta al servizio ricevente:
- Un'intestazione
Authorization: Bearer ID_TOKEN. - Un'intestazione
X-Serverless-Authorization: Bearer ID_TOKEN. Puoi utilizzare questa intestazione se la tua applicazione utilizza già l'intestazioneAuthorizationper l'autorizzazione personalizzata. In questo modo, la firma viene rimossa prima di passare il token al container utente.
- Un'intestazione
Per altri modi per ottenere un token ID non descritti in questa pagina, consulta Metodi per ottenere un token ID.
Utilizzare le librerie di autenticazione
Un modo per acquisire e configurare il processo del token ID è utilizzare le librerie di autenticazione.
Questo codice funziona in qualsiasi ambiente, anche al di fuori di Google Cloud,
in cui le librerie possono ottenere le credenziali di autenticazione per un service
account. Per utilizzare questo metodo,
scarica un file della chiave del service account e
imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS sul percorso del
file della chiave del account di servizio. Per saperne di più, consulta la sezione
Chiave del service account.
Questo codice non accetta le credenziali di autenticazione per un account utente.
Node.js
Python
Go
Java
Utilizzare il server di metadati
Se per qualche motivo non puoi utilizzare le librerie di autenticazione, puoi recuperare un token ID dal server dei metadati Compute mentre il container è in esecuzione su Cloud Run. Tieni presente che questo metodo non funziona al di fuori di Google Cloud, inclusa la macchina locale.
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=[AUDIENCE]" \
-H "Metadata-Flavor: Google"
Dove AUDIENCE è l'URL del servizio che stai richiamando o un segmento di pubblico personalizzato configurato.
La tabella seguente riassume le parti principali di una richiesta di query dei metadati:
| Componenti | Descrizione |
|---|---|
| URL di base | Tutti i valori dei metadati sono definiti come sotto-percorsi sotto il seguente URL di base: http://metadata.google.internal/computeMetadata/v1 |
| Intestazione della richiesta | La seguente intestazione deve essere presente in ogni richiesta: Metadata-Flavor: Google Questa intestazione indica che la richiesta è stata inviata con l'intenzione di recuperare valori dei metadati, piuttosto che involontariamente da un'origine non sicura, e consente al server dei metadati di restituire i dati richiesti. Se non fornisci questa intestazione, il server dei metadati nega la richiesta. |
Per una procedura dettagliata end-to-end di un'applicazione che utilizza questa tecnica di autenticazione tra servizi, segui il tutorial Proteggere i servizi Cloud Run.
Utilizzare la federazione delle identità per i carichi di lavoro dall'esterno Google Cloud
Se il tuo ambiente utilizza un provider di identità supportato dalla federazione delle identità per i workload, puoi utilizzare il seguente metodo per eseguire l'autenticazione in modo sicuro al tuo servizio Cloud Run dall'esterno Google Cloud:
Configura il account di servizio come descritto in Configurare il service account in questa pagina.
Configura la federazione delle identità per i workload per il tuo provider di identità come descritto in Configurare la federazione delle identità per i workload.
Segui le istruzioni riportate in Concedere alle identità esterne l'autorizzazione a rappresentare un service account.
Utilizza l'API REST per acquisire un token di breve durata, ma anziché chiamare
generateAccessTokenper ottenere un token di accesso, chiamagenerateIdTokenper ottenere un token ID.Ad esempio, utilizzando cURL:
ID_TOKEN=$(curl -0 -X POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT:generateIdToken \ -H "Content-Type: text/json; charset=utf-8" \ -H "Authorization: Bearer $STS_TOKEN" \ -d @- <<EOF | jq -r .token { "audience": "SERVICE_URL" } EOF ) echo $ID_TOKEN
Dove
SERVICE_ACCOUNTè l'indirizzo email del service account configurato per accedere al pool di identità del workload eSERVICE_URLè l'URL del servizio Cloud Run che stai richiamando. Questo valore deve rimanere l'URL del servizio, anche quando effettui richieste a un tag di traffico specifico.$STS_TOKENè il token del servizio token di sicurezza che hai ricevuto nel passaggio precedente nelle istruzioni relative alla federazione delle identità per i workload.
Puoi includere il token ID del passaggio precedente nella richiesta al
servizio utilizzando un'intestazione Authorization: Bearer ID_TOKEN
o un'intestazione X-Serverless-Authorization: Bearer ID_TOKEN. Se vengono fornite entrambe le intestazioni, viene controllata solo l'intestazione X-Serverless-Authorization.
Utilizzare una chiave del account di servizio scaricata dall'esterno Google Cloud
Se la federazione delle identità per i workload non è appropriata per il tuo ambiente, puoi utilizzare una chiave account di servizio scaricata per eseguire l'autenticazione dall'esterno di Google Cloud. Aggiorna il codice client in modo che utilizzi le librerie di autenticazione come descritto in precedenza. Per saperne di più, consulta la sezione Chiave del service account.
Puoi acquisire un token ID firmato da Google utilizzando un JWT autofirmato, ma questa operazione è piuttosto complicata e potenzialmente soggetta a errori. I passaggi di base sono i seguenti:
Firma autonomamente un JWT del account di servizio con l'attestazione
target_audienceimpostata sull' URL del servizio ricevente o su un segmento di pubblico personalizzato configurato. Se non utilizzi domini personalizzati, il valoretarget_audiencedeve rimanere l' URL del servizio, anche quando effettui richieste a un tag di traffico specifico.Scambia il JWT autofirmato con un token ID firmato da Google, che deve avere l'attestazione
audimpostata sull'URL precedente.Includi il token ID nella richiesta al servizio utilizzando un'intestazione
Authorization: Bearer ID_TOKENo un'intestazioneX-Serverless-Authorization: Bearer ID_TOKEN. Se vengono fornite entrambe le intestazioni, viene controllata solo l'intestazioneX-Serverless-Authorization.
Ricevere richieste autenticate
All'interno del servizio privato ricevente, puoi analizzare l'intestazione di autorizzazione per ricevere le informazioni inviate dal token portatore.
Python
Passaggi successivi
- Scopri di più sulla convalida dei token ID