Introduzione all'identità del servizio

Questa pagina descrive le due identità Cloud Run e come le librerie client Cloud utilizzano l'identità del servizio per chiamare le API. Google Cloud Esempi di Google Cloud prodotti che dispongono delle librerie client Cloud includono Cloud Storage, Firestore, Cloud SQL, Pub/Sub e Cloud Tasks. Questa pagina è rivolta ad amministratori, operatori o sviluppatori che gestiscono i criteri dell'organizzazione e l'accesso degli utenti o a chiunque voglia saperne di più su questi argomenti.

Identità Cloud Run

Per utilizzare Cloud Run, Google Cloud richiede che l'utente Cloud Run e l'istanza Cloud Run abbiano ciascuno un'identità.

  • L'identità dell'utente Cloud Run è denominata account di deployment Cloud Run. Quando gestisci una revisione o un job, utilizzi questa identità per effettuare richieste all'API Cloud Run Admin.
  • L'identità dell'istanza Cloud Run è denominata identità del servizio Cloud Run. Quando il codice Cloud Run che hai scritto interagisce con le librerie client di Cloud o chiama un altro servizio Cloud Run per la comunicazione da servizio a servizio, utilizzi questa identità per effettuare richieste da Cloud Run alle APIGoogle Cloud o ad altri servizi Cloud Run.

Per accedere alle Google Cloud API o comunicare tra i servizi ed effettuare richieste, ogni identità deve disporre delle autorizzazioni appropriate concesse in Identity and Access Management (IAM).

Chiama l'API Cloud Run Admin con l'account del programma di deployment

Puoi chiamare l'API Cloud Run Admin da Cloud Run utilizzando l'account di deployment di Cloud Run. L'account di deployment può essere un account utente o un account di servizio e rappresenta l'account con cui è stato eseguito l'accesso all'ambiente Google Cloud .

Quando l'account di deployment utilizza Cloud Run, IAM verifica se l'account di deployment dispone delle autorizzazioni necessarie per eseguire l'operazione Cloud Run. Il seguente diagramma mostra come un account utente chiama l'API Cloud Run Admin per eseguire il deployment di una nuova revisione dalla consoleGoogle Cloud :

Chiama l'API Cloud Run Admin dalla console Google Cloud .
Figura 1. Un utente utilizza la console Google Cloud per eseguire il deployment di una nuova revisione inviando una richiesta con un token di accesso all'API Cloud Run Admin. IAM utilizza questo token di accesso per verificare che l'account utente sia autenticato per accedere all'API Cloud Run Admin prima di eseguire l'operazione.

Chiamare le API Google Cloud con l'identità del servizio

Quando un'istanza Cloud Run interagisce con altri servizi Cloud Run autenticati con IAM o chiama le librerie client Cloud tramite codice dell'applicazione o funzionalità integrate come le integrazioni di Cloud Run o i montaggi di volumi Cloud Storage, l'ambiente Google Cloud utilizza le credenziali predefinite dell'applicazione (ADC) per rilevare automaticamente se l'identità del servizio Cloud Run è autenticata per eseguire l'operazione API. L'identità del servizio Cloud Run è un account di servizio assegnato come identità dell'istanza Cloud Run quando esegui il deployment di una revisione o esegui un job.

Un account di servizio utilizzato come account di deployment verrà utilizzato come identità di servizio solo se configuri lo stessoaccount di serviziot nella configurazione di Cloud Run.

Il resto di questa guida descrive come un servizio o un job Cloud Run utilizza l'identità del servizio per chiamare e accedere ai servizi e alle API di Google. Per ulteriori informazioni sulla configurazione dell'identità del servizio, consulta le pagine di configurazione dell'identità del servizio per servizi e job.

Tipi di service account per l'identità del servizio

Quando l'istanza Cloud Run effettua chiamate alle API Google Cloud per eseguire le operazioni necessarie, Cloud Run utilizza automaticamente un account di servizio come identità del servizio. I due tipi di service account che possono essere utilizzati come identità del servizio sono i seguenti:

  • Service account di servizio gestito dall'utente (consigliato): crei manualmente questo account di servizio e determini l'insieme minimo di autorizzazioni di cui ha bisogno per accedere a risorse Google Cloud specifiche. Il account di servizio gestito dall'utente segue il formato SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com.
  • Service account predefinito di Compute Engine: Cloud Run fornisce automaticamente ilaccount di serviziot predefinito di Compute Engine come identità di servizio predefinita. Il account di servizio Compute Engine predefinito segue il formato PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Evita il account di servizio predefinito quando configuri l'identità del servizio

Per impostazione predefinita, l'account di servizio predefinito di Compute Engine viene creato automaticamente. Se non specifichi un account di servizio quando viene creato il servizio o il job Cloud Run, Cloud Run utilizza questo account di servizio.

A seconda della configurazione della policy dell'organizzazione, al account di servizio predefinito potrebbe essere concesso automaticamente il ruolo Editor nel tuo progetto. Ti consigliamo vivamente di disattivare la concessione automatica dei ruoli applicando il vincolo iam.automaticIamGrantsForDefaultServiceAccounts del criterio dell'organizzazione. Se hai creato la tua organizzazione dopo il 3 maggio 2024, questo vincolo viene applicato per impostazione predefinita.

Se disattivi la concessione automatica dei ruoli, devi decidere quali ruoli concedere agli account di servizio predefiniti e poi concederli personalmente.

Se l'account di servizio predefinito dispone già del ruolo Editor, ti consigliamo di sostituirlo con ruoli meno permissivi.Per modificare in modo sicuro i ruoli dell'account di servizio, utilizza Policy Simulator per visualizzare l'impatto della modifica, quindi concedi e revoca i ruoli appropriati.

Come funziona l'identità del servizio

Quando il codice chiama o effettua richieste alle librerie client Cloud, si verifica quanto segue:

  1. Le librerie client rilevano che viene effettuata una richiesta a un'API o alle librerie client di Cloud e richiedono un token di accesso OAuth 2.0 per l'identità del servizio dal server dei metadati dell'istanza. Google Cloud
  2. Il server dei metadati dell'istanza fornisce un token di accesso IAM per ilaccount di serviziot configurato come identità del servizio.
  3. La richiesta all'API Google Cloud viene inviata con un token di accesso OAuth 2.0.
  4. IAM verifica l'identità del servizio a cui viene fatto riferimento nel token di accesso per le autorizzazioni necessarie e controlla i binding dei criteri prima di inoltrare la chiamata all'endpoint API.
  5. L'API Google Cloud esegue l'operazione.
Chiama l'API Google Cloud da Cloud Run.
Figura 1. Cloud Run genera un token di accesso dal server di metadati e IAM utilizza questo token di accesso per verificare che l'identità del servizio Cloud Run assegnata sia autenticata per accedere alle Google Cloud API.

Genera un token di accesso per la richiesta Cloud Run per chiamare le API Google Cloud

Se il codice Cloud Run utilizza le librerie client Cloud, configuri l'identità del servizio in Cloud Run assegnando uaccount di serviziont al deployment o all'esecuzione. In questo modo, la libreria acquisisce automaticamente un token di accesso per autenticare la richiesta del codice. Se il codice Cloud Run comunica con altri servizi Cloud Run autenticati, devi aggiungere il token di accesso alle tue richieste.

Per assegnare un account di servizio come identità del servizio, consulta le seguenti guide:

Tuttavia, se utilizzi un codice personalizzato o devi effettuare richieste in modo programmatico, puoi utilizzare direttamente il server dei metadati per recuperare manualmente i token ID e i token di accesso descritti nella sezione successiva. Tieni presente che non puoi eseguire query su questo server direttamente dalla tua macchina locale, in quanto il server di metadati è disponibile solo per i workload in esecuzione suGoogle Cloud.

Recuperare token ID e di accesso utilizzando il server di metadati

I due tipi di token che puoi recuperare con il server dei metadati sono i seguenti:

  • Token di accesso OAuth 2.0, utilizzati per chiamare la maggior parte delle librerie client delle API di Google.
  • Token ID, utilizzati per chiamare altri servizi Cloud Run o per richiamare qualsiasi servizio per convalidare un token ID.

Per recuperare un token, segui le istruzioni nella scheda appropriata per il tipo di token che stai utilizzando:

Token di accesso

Ad esempio, se vuoi creare un argomento Pub/Sub, utilizza il metodo projects.topics.create.

  1. Utilizza il server metadati di Compute per recuperare un token di accesso:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
        --header "Metadata-Flavor: Google"

    Questo endpoint restituisce una risposta JSON con un attributo access_token.

  2. Nella richiesta del protocollo HTTP, la richiesta deve essere autenticata con un token di accesso nell'intestazione Authorization:

    PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/topics/TOPIC_ID
    Authorization: Bearer ACCESS_TOKEN
    

    Dove:

    • PROJECT_ID è l'ID progetto.
    • TOPIC_ID è l'ID del tuo argomento.
    • ACCESS_TOKEN è il token di accesso recuperato nel passaggio precedente.

    Risposta:

    {
        "name": "projects/PROJECT_ID/topics/TOPIC_ID"
    }
    

Token ID

Utilizza il server dei metadati di Compute per recuperare un token ID con un pubblico specifico:

curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=AUDIENCE" \
    --header "Metadata-Flavor: Google"

Dove AUDIENCE è il pubblico JWT richiesto.

Per i servizi Cloud Run, il pubblico deve essere l'URL del servizio che stai richiamando o un pubblico personalizzato, ad esempio un dominio personalizzato, configurato per il servizio.

https://service.domain.com

Per altre risorse, è probabile che si tratti dell'ID client OAuth di una risorsa protetta da IAP:

1234567890.apps.googleusercontent.com

Passaggi successivi