Se la tua architettura usa più servizi, questi che probabilmente hanno bisogno di comunicare tra loro, utilizzando 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 servizi Google Cloud:
- Cloud Tasks per una comunicazione asincrona
- Pub/Sub per la comunicazione asincrona one-to-many, one-to-one e many-to-one
- 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 che hai impostato.
Tuttavia, per la comunicazione sincrona, il servizio chiama un altro servizio direttamente tramite HTTP utilizzando l'URL dell'endpoint. Per questo caso d'uso, devi assicurarti che ogni servizio possa inviare richieste solo a servizi specifici. Ad esempio, se hai un servizio login
, questo dovrebbe essere in grado
per 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 account di servizio gestito dall'utente per ogni 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. Per farlo, configura il servizio di chiamata per aggiungere un OpenID Connect firmato da Google ID token di sicurezza nell'ambito della richiesta.
Configura l'account di servizio
Per impostare un account di servizio, devi configurare il servizio ricevente in modo che accetti le richieste da
al servizio chiamante rendendo l'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 le operazioni, segui le istruzioni nella scheda appropriata:
Interfaccia utente della console
Vai alla console Google Cloud:
Seleziona il servizio di destinazione.
Fai clic su Mostra riquadro informazioni nell'angolo in alto a destra per visualizzare le Scheda Autorizzazioni.
Fai clic su Aggiungi entità.
Inserisci l'identità del servizio chiamante. Di solito 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 di destinazione e CALLING_SERVICE_IDENTITY
è l'indirizzo email dell'account di servizio, per impostazione predefinitaPROJECT_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 dovrebbe essere pubblico.
Sostituisci us-docker.pkg.dev/cloudrun/container/hello
con un riferimento all'immagine container.
Il codice Terraform seguente rende pubblico il servizio iniziale.
Il codice Terraform seguente 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 appropriato all'account di servizio chiamante, segui questi passaggi passaggi:
Recupera un token ID firmato da Google utilizzando uno dei metodi descritti nella sezione che segue. Imposta la rivendicazione del segmento di pubblico (
aud
) sull'URL del servizio di ricezione o su un segmento di pubblico personalizzato configurato. Se non utilizzi un segmento di pubblico personalizzato, il valoreaud
deve rimanere invariato URL del servizio, anche quando si effettuano richieste a un traffico specifico del tag.Aggiungi il token ID recuperato dal passaggio precedente in uno dei seguenti nella richiesta al servizio ricevente:
- Un'intestazione
Authorization: Bearer ID_TOKEN
. - Un'intestazione
X-Serverless-Authorization: Bearer ID_TOKEN
. Puoi utilizzare questo se la tua applicazione utilizza già l'intestazioneAuthorization
per autorizzazione. In questo modo la firma viene rimossa prima di trasmetterlo all'utente containerizzato.
- 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
Il modo più semplice e affidabile per acquisire e configurare il processo di token ID
consiste nell'utilizzare le librerie di autenticazione.
Questo codice funziona in qualsiasi ambiente, anche al di fuori di Google Cloud,
dove le librerie possono ottenere le credenziali di autenticazione per un account
di servizio, inclusi gli ambienti
che supportano le credenziali predefinite dell'applicazione locali.
Per impostare
credenziali predefinite dell'applicazione,
scaricare un file della chiave dell'account di servizio e
imposta la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS
sul percorso del
e il file delle chiavi
dell'account di servizio. Per ulteriori informazioni, consulta
Come funzionano le credenziali predefinite dell'applicazione.
Questo codice non funziona per ottenere le credenziali di autenticazione per un account utente.
Node.js
Python
Vai
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 di Compute mentre il contenitore è 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 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 sui metadati:
Componenti | Descrizione |
---|---|
URL di base | Tutti i valori dei metadati sono definiti come sottopercorsi 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 anziché provenienti involontariamente da un'origine non sicura, il server dei metadati restituisce i dati richiesti. Se non fornisci questo , il server dei metadati rifiuta la tua richiesta. |
Per una procedura dettagliata end-to-end di un'applicazione che utilizza questo servizio di autenticazione, segui le tutorial sulla protezione dei servizi Cloud Run.
Utilizzare la federazione delle identità per i carichi di lavoro dall'esterno di Google Cloud
Se il tuo ambiente utilizza un provider di identità supportato da federazione delle identità per i carichi di lavoro, usare il seguente metodo per eseguire l'autenticazione sicura sul tuo Servizio Cloud Run esterno a 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 riportate in Concedere alle identità esterne l'autorizzazione a simulare l'identità di un account di servizio.
Utilizzare l'API REST per acquisire un token di breve durata, ma invece di chiamare
generateAccessToken
: per ottenere un token di accesso, richiamagenerateIdToken
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 il pool di identità per i carichi di lavoro è configurato per accedere eSERVICE_URL
è l'URL del servizio Cloud Run che stai richiamando. Questo valore deve rimanere l'URL del servizio, anche quando vengono effettuate richieste a un tag di traffico specifico.$STS_TOKEN
è il token di servizio del token di sicurezza che ricevuto nel passaggio precedente nelle istruzioni della federazione delle identità per i carichi di lavoro.
Puoi includere nella richiesta al parametro il token ID del passaggio precedente
un servizio tramite un Authorization: Bearer ID_TOKEN
un'intestazione X-Serverless-Authorization: Bearer ID_TOKEN
. Se
sono fornite entrambe le intestazioni, solo X-Serverless-Authorization
sia selezionata.
Utilizzare 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 l'autenticazione dall'esterno di Google Cloud. Aggiorna il codice client in modo da utilizzare le librerie di autenticazione come descritto in precedenza con le Credenziali predefinite dell'applicazione.
Puoi acquisire un token ID firmato da Google utilizzando un JWT autofirmato, ma si tratta di piuttosto complicata e potenzialmente soggetta a errori. I passaggi di base sono i seguenti:
Firma autonomamente il JWT di un account di servizio con l'attestazione
target_audience
impostata su URL del servizio ricevente o di un segmento di pubblico personalizzato configurato. Se non utilizzi domini personalizzati, il valoretarget_audience
deve rimanere come URL del servizio, anche quando si effettuano richieste a un traffico specifico del tag.Sostituisci il token JWT autofirmato con un token ID firmato da Google, che deve avere il claim
aud
impostato sull'URL precedente.Includi il token ID nella richiesta al servizio utilizzando un
Authorization: Bearer ID_TOKEN
un'intestazioneX-Serverless-Authorization: Bearer ID_TOKEN
. Se vengono fornite entrambe le intestazioni, soloX-Serverless-Authorization
sia selezionata.
Ricevere richieste autenticate
All'interno del servizio privato ricevente, puoi analizzare l'intestazione dell'autorizzazione riceveranno le informazioni inviate dal token di connessione.