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 pertanto richiedono credenziali per l'accesso.
Per la comunicazione asincrona, puoi utilizzare i seguenti servizi Google Cloud:
- Cloud Tasks per una comunicazione asincrona individuale
- Pub/Sub per la comunicazione asincrona da uno a uno, uno a uno e da molti a uno
- Cloud Scheduler per una comunicazione asincrona pianificata regolarmente
- Eventarc per la comunicazione basata sugli eventi
In tutti questi casi, il servizio utilizzato gestisce l'interazione con il servizio ricevente, in base alla configurazione che hai impostato.
Tuttavia, per la comunicazione sincrona, il servizio chiama un altro servizio direttamente, tramite HTTP, utilizzando il relativo 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 dovrebbe essere in grado di accedere al servizio user-profiles
, ma non al servizio search
.
In questo caso, Google consiglia di utilizzare IAM e un'identità di servizio basata su un account di servizio gestito dall'utente per servizio a cui è stato concesso l'insieme minimo di autorizzazioni necessarie per svolgere il proprio lavoro.
Inoltre, la richiesta deve presentare una prova dell'identità del servizio chiamante. A questo scopo, configura il servizio di chiamata in modo da aggiungere un token ID OpenID Connect firmato da Google come parte della richiesta.
Configura l'account di servizio
Per impostare un account di servizio, configura il servizio ricevente in modo che accetti le richieste del servizio di chiamata rendendo l'account di servizio del servizio di chiamata come entità del servizio ricevente. Quindi concederai a quell'account di servizio il ruolo Invoker di Cloud Run (roles/run.invoker
). Per eseguire entrambe le operazioni, segui le istruzioni nella scheda appropriata:
Interfaccia utente della console
Vai alla console Google Cloud:
Seleziona il servizio di ricezione.
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 Invoker
dal menu a discesa Seleziona un ruolo.Fai clic su Salva.
gcloud
Usa 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 dell'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.
Il seguente codice Terraform crea un servizio Cloud Run iniziale che deve essere pubblico.
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 all'account di servizio di richiamare il servizio Cloud Run privato iniziale.
Acquisisci e configura il token ID
Dopo aver concesso il ruolo corretto all'account di servizio per le chiamate, segui questi passaggi:
Recupera un token ID firmato da Google utilizzando uno dei metodi descritti nella sezione seguente. Imposta la rivendicazione del segmento di pubblico (
aud
) sull'URL del servizio ricevente o su un segmento di pubblico personalizzato configurato. Se non utilizzi un segmento di pubblico personalizzato, il valoreaud
deve rimanere come URL del servizio, anche quando vengono effettuate richieste a un tag di traffico specifico.Aggiungi il token ID che hai recuperato dal passaggio precedente a una delle seguenti intestazioni della richiesta al servizio di destinazione:
- 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'intestazioneAuthorization
per l'autorizzazione personalizzata. In questo modo viene rimossa la firma prima di trasmettere il token al container dell'utente.
- Un'intestazione
Per altri modi per ottenere un token ID non descritti in questa pagina, consulta la sezione Metodi per ottenere un token ID.
Utilizzare le librerie di autenticazione
Il modo più semplice e affidabile per gestire questo processo è utilizzare le librerie di autenticazione, come mostrato di seguito, per generare e utilizzare questo token. Questo codice funziona in qualsiasi ambiente, anche all'esterno di Google Cloud, in cui le librerie possono ottenere le credenziali di autenticazione per un account di servizio, inclusi gli ambienti che supportano credenziali predefinite dell'applicazione locali. Tuttavia, il codice non funziona per ottenere le credenziali di autenticazione per un account utente.
Node.js
Python
Go
Java
Utilizzare il server dei metadati
Se per qualche motivo non puoi utilizzare le librerie di autenticazione, puoi recuperare un token ID dal server di metadati Compute mentre il container è in esecuzione su Cloud Run. Tieni presente che questo metodo non funziona al di fuori di Google Cloud, nemmeno dalla tua macchina locale.
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=[AUDIENCE]" \
-H "Metadata-Flavor: Google"
Dove PUBBLICO è l'URL del servizio che stai richiamando o di un segmento di pubblico personalizzato configurato.
La seguente tabella riassume le parti principali di una richiesta di query sui metadati:
Componenti | Descrizione |
---|---|
URL principale | Tutti i valori dei metadati sono definiti come percorsi secondari al di sotto del seguente URL principale: http://metadata.google.internal/computeMetadata/v1 |
Intestazione della richiesta | In ogni richiesta deve essere presente la seguente intestazione: Metadata-Flavor: Google Questa intestazione indica che la richiesta è stata inviata con l'intento di recuperare i valori dei metadati, anziché 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 rifiuta la tua richiesta. |
Per una procedura dettagliata end-to-end di un'applicazione che utilizza questa tecnica di autenticazione service-to-service, segui il tutorial per la protezione dei servizi Cloud Run.
Utilizza la federazione delle identità per i carichi di lavoro dall'esterno di Google Cloud
Se il tuo ambiente utilizza un provider di identità supportato dalla federazione delle identità per i carichi di lavoro, puoi utilizzare il seguente metodo per eseguire l'autenticazione in modo sicuro al servizio Cloud Run dall'esterno di Google Cloud:
Configura l'account di servizio come descritto in Configurare l'account di servizio in questa pagina.
Configura la federazione delle identità per i carichi di lavoro per il tuo provider di identità come descritto in Configurazione della federazione delle identità per i carichi di lavoro.
Segui le istruzioni in Concessione dell'autorizzazione per identità esterne per impersonare un account di servizio.
Utilizza l'API REST per acquisire un token di breve durata, ma invece di chiamare
generateAccessToken
per ottenere un token di accesso, chiamagenerateIdToken
per 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 dell'account di servizio a cui è configurato il pool di identità per i carichi di lavoro eSERVICE_URL
è l'URL del servizio Cloud Run che stai richiamando. Questo valore deve rimanere come URL del servizio, anche quando si effettuano richieste a un tag di traffico specifico.$STS_TOKEN
è il token del servizio token di sicurezza che hai ricevuto nel passaggio precedente nelle istruzioni della federazione delle identità per i carichi di lavoro.
Puoi includere nella richiesta al servizio il token ID del passaggio precedente utilizzando un'intestazione Authorization: Bearer ID_TOKEN
o X-Serverless-Authorization: Bearer ID_TOKEN
. Se vengono fornite entrambe le intestazioni, viene selezionata solo l'intestazione X-Serverless-Authorization
.
Usa una chiave dell'account di servizio scaricata dall'esterno di Google Cloud
Se la federazione delle identità per i carichi di lavoro non è appropriata per il tuo ambiente, puoi utilizzare una chiave dell'account di servizio scaricata per eseguire l'autenticazione dall'esterno di Google Cloud. Aggiorna il codice client per utilizzare le librerie di autenticazione come descritto in precedenza con Credenziali predefinite dell'applicazione.
Puoi acquisire un token ID firmato da Google utilizzando un JWT autofirmato, ma è piuttosto complicato e potenzialmente soggetto a errori. I passaggi di base sono i seguenti:
Firma autonomamente un JWT dell'account di servizio con la rivendicazione
target_audience
impostata sull'URL del servizio ricevente o su un segmento di pubblico personalizzato configurato. Se non utilizzi domini personalizzati, il valoretarget_audience
deve rimanere l'URL del servizio, anche quando si effettuano richieste a un tag di traffico specifico.Scambia il JWT autofirmato con un token ID firmato da Google, che deve avere la rivendicazione
aud
impostata sull'URL precedente.Includi il token ID nella richiesta al servizio utilizzando un'intestazione
Authorization: Bearer ID_TOKEN
oX-Serverless-Authorization: Bearer ID_TOKEN
. Se vengono fornite entrambe le intestazioni, viene selezionata solo l'intestazioneX-Serverless-Authorization
.
Puoi esaminare questo esempio di Cloud Functions per avere un esempio dei passaggi precedenti.
Ricevi richieste autenticate
All'interno del servizio privato di ricezione, puoi analizzare l'intestazione di autorizzazione per ricevere le informazioni inviate dal token di connessione.