Account di servizio

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa pagina spiega gli account di servizio, i tipi di account di servizio e i ruoli IAM disponibili per gli account di servizio.

Prima di iniziare

  • Impara i concetti alla base di IAM.

Che cosa sono gli account di servizio?

Un account di servizio è un particolare tipo di account utilizzato da un'applicazione o da un carico di lavoro di calcolo, ad esempio un'istanza di macchina virtuale (VM) Compute Engine, anziché una persona. Un account di servizio è identificato dal suo indirizzo email, che è univoco per l'account.

Le applicazioni utilizzano gli account di servizio per effettuare chiamate API autorizzate mediante autenticazione come account di servizio stesso o come utenti di Google Workspace o Cloud Identity tramite la delega a livello di dominio.

Ad esempio, un account di servizio può essere collegato a una VM di Compute Engine, in modo che le applicazioni in esecuzione su tale VM possano autenticarsi come account di servizio. Inoltre, all'account di servizio possono essere assegnati ruoli IAM che le consentono di accedere alle risorse. L'account di servizio viene utilizzato come identità dell'applicazione e i ruoli dell'account di servizio controllano le risorse a cui può accedere.

Esistono altri modi per eseguire l'autenticazione come account di servizio. Ad esempio, con Google Cloud CLI, puoi utilizzare il flag --impersonate-service-account per autenticarti come account di servizio quando esegui un comando. Puoi anche creare una chiave dell'account di servizio e utilizzarla per ottenere i token di accesso OAuth 2.0.

Differenze tra un account di servizio e un account utente

Gli account di servizio si differenziano dagli account utente per alcuni aspetti fondamentali:

  • Gli account di servizio non hanno password e non possono accedervi tramite browser o cookie.
  • Gli account di servizio sono associati a coppie di chiavi RSA pubbliche/private utilizzate per più scopi, ad esempio per la firma dei dati.
  • Puoi consentire ad altri utenti o account di servizio di impersonare un account di servizio.
  • A differenza degli account utente, gli account di servizio non appartengono al tuo dominio Google Workspace. Se condividi gli asset di Google Workspace, ad esempio documenti o eventi, con l'intero dominio Google Workspace, questi non vengono condivisi con gli account di servizio. Analogamente, gli asset di Google Workspace creati da un account di servizio non vengono creati nel dominio Google Workspace. Di conseguenza, gli amministratori di Google Workspace e Cloud Identity non possono possedere o gestire questi asset.

Prevenzione della creazione di account di servizio

Puoi impedire la creazione di account di servizio applicando il constraints/iam.disableServiceAccountCreation vincolo dei criteri dell'organizzazione in un'organizzazione, un progetto o una cartella.

Prima di applicare questo vincolo, tieni in considerazione le seguenti limitazioni:

Account di servizio e gruppi Google

Puoi aggiungere account di servizio a un gruppo Google, quindi concedere ruoli al gruppo. Tuttavia, l'aggiunta di account di servizio ai gruppi non è una best practice. Gli account di servizio vengono utilizzati dalle applicazioni e probabilmente ogni applicazione avrà i propri requisiti di accesso.

Tipi di account di servizio

Account di servizio gestiti dall'utente

Puoi creare account di servizio gestiti dall'utente nel tuo progetto utilizzando l'API IAM, la console Google Cloud o Google Cloud CLI. È tua responsabilità gestire e proteggere questi account.

Per impostazione predefinita, puoi creare fino a 100 account di servizio gestiti dall'utente in un progetto. Se questa quota non soddisfa le tue esigenze, puoi utilizzare la console Google Cloud per richiedere un aumento della quota. Gli account di servizio predefiniti descritti in questa pagina non incidono su questa quota.

Quando crei un account di servizio gestito dall'utente nel tuo progetto, scegli un nome per l'account di servizio. Questo nome viene visualizzato nell'indirizzo email che identifica l'account di servizio, che utilizza il seguente formato:

service-account-name@project-id.iam.gserviceaccount.com

Account di servizio predefiniti

Quando abiliti o utilizzi alcuni servizi Google Cloud, questi creano account di servizio gestiti dall'utente che consentono al servizio di eseguire il deployment di job che accedono ad altre risorse di Google Cloud. Questi account sono noti come account di servizio predefiniti.

Se la tua applicazione viene eseguita in un ambiente Google Cloud con un account di servizio predefinito, l'applicazione può utilizzare le credenziali per tale account per chiamare le API Google Cloud. In alternativa, puoi creare il tuo account di servizio gestito dall'utente e utilizzarlo per l'autenticazione. Per maggiori dettagli, vedi Trovare automaticamente le credenziali.

Nella tabella seguente sono elencati i servizi che creano gli account di servizio predefiniti:

Servizio Nome account di servizio Indirizzo email
App Engine e qualsiasi servizio Google Cloud che utilizza App Engine Account di servizio predefinito di App Engine project-id@appspot.gserviceaccount.com
Compute Engine e qualsiasi servizio Google Cloud che utilizza Compute Engine Account di servizio predefinito Compute Engine project-number-compute@developer.gserviceaccount.com

Account di servizio gestiti da Google

Alcuni servizi Google Cloud richiedono l'accesso alle risorse per poter agire per tuo conto. Ad esempio, quando utilizzi Cloud Run per eseguire un container, il servizio ha bisogno di accedere a tutti gli argomenti Pub/Sub che possono attivare il container.

Per soddisfare questa esigenza, Google crea e gestisce account di servizio per molti servizi Google Cloud. Questi account sono noti come account di servizio gestiti da Google. Potresti visualizzare gli account di servizio gestiti da Google nel criterio di autorizzazione del progetto, nei log di controllo o nella pagina IAM della console Google Cloud.

Gli account di servizio gestiti da Google non sono elencati nella pagina Account di servizio nella console Google Cloud. Questi account di servizio non si trovano nel tuo progetto e non puoi accedervi direttamente.

Ad esempio:

  • Agente di servizio delle API di Google. È probabile che il criterio di autorizzazione del progetto faccia riferimento a un account di servizio denominato Agente di servizio API di Google, con un indirizzo email che utilizza il seguente formato: project-number@cloudservices.gserviceaccount.com

    Questo account di servizio esegue processi interni di Google per tuo conto. Viene concesso automaticamente il ruolo Editor (roles/editor) nel progetto.

  • Altri agenti di servizio. Il criterio di autorizzazione del progetto potrebbe fare riferimento ad altri account di servizio gestiti da Google che agiscono per conto di singoli servizi. Questi account di servizio sono chiamati agenti di servizio. I ruoli potrebbero essere concessi automaticamente a questi agenti di servizio; di solito, i nomi di questi ruoli terminano con serviceAgent.

    Per un elenco completo degli agenti di servizio e dei ruoli concessi automaticamente a ciascuno, consulta Agenti di servizio.

  • Gestore dei ruoli per gli account di servizio gestiti da Google. I log di controllo per IAM potrebbero fare riferimento all'account di servizio service-agent-manager@system.gserviceaccount.com.

    Questo account di servizio gestisce i ruoli concessi ad altri account di servizio gestiti da Google. È visibile solo negli audit log.

    Ad esempio, se utilizzi una nuova API, Google potrebbe creare automaticamente un nuovo account di servizio gestito da Google e concedere ruoli all'account di servizio nel tuo progetto. La concessione di questi ruoli genera una voce di log di controllo, che mostra che service-agent-manager@system.gserviceaccount.com ha impostato il criterio di autorizzazione per il progetto.

Località dell'account di servizio

Ogni account di servizio si trova in un progetto. Dopo aver creato un account di servizio, non puoi spostarlo in un progetto diverso.

Esistono alcuni modi per organizzare gli account di servizio in progetti:

  • Crea account di servizio e risorse nello stesso progetto.

    Questo approccio semplifica l'uso degli account di servizio. Tuttavia, può essere difficile tenere traccia degli account di servizio quando sono distribuiti in più progetti.

  • Centralizza gli account di servizio in progetti separati.

    Questo approccio consente di inserire tutti gli account di servizio per l'organizzazione in un numero ridotto di progetti, semplificando la gestione degli account. Tuttavia, richiede una configurazione aggiuntiva se colleghi account di servizio alle risorse in altri progetti, consentendo a queste risorse di utilizzare l'account di servizio come identità.

    Quando un account di servizio si trova in un progetto e accede a una risorsa in un altro progetto, in genere devi abilitare l'API per quella risorsa in entrambi i progetti. Ad esempio, se hai un account di servizio nel progetto my-service-accounts e un'istanza Cloud SQL nel progetto my-application, devi abilitare l'API Cloud SQL sia in my-service-accounts che in my-application.

    Per impostazione predefinita, puoi creare fino a 100 account di servizio in un progetto. Se devi creare altri account di servizio, richiedi un aumento della quota.

Autorizzazioni account di servizio

Gli account di servizio sono sia identità sia risorse.

Poiché gli account di servizio sono identità, puoi consentire a un account di servizio di accedere alle risorse del progetto assegnandogli un ruolo, proprio come faresti per qualsiasi altra entità. Ad esempio, se vuoi consentire all'account di servizio dell'applicazione di accedere agli oggetti in un bucket Cloud Storage, puoi concedere all'account di servizio il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) nel bucket.

Per ulteriori informazioni sulla concessione dei ruoli alle entità, inclusi gli account di servizio, consulta Concedere, modificare e revocare l'accesso.

Tuttavia, gli account di servizio sono anche risorse che accettano i criteri di autorizzazione. Di conseguenza, puoi consentire ad altre entità di accedere a un account di servizio assegnando loro un ruolo nell'account di servizio o in una delle risorse padre dell'account di servizio. Ad esempio, per consentire a un utente di impersonare un account di servizio, puoi concedergli il ruolo Utente account di servizio (roles/iam.serviceAccountUser) nell'account di servizio.

Per ulteriori informazioni sulla concessione dei ruoli alle entità, inclusi gli account di servizio, consulta Concedere, modificare e revocare l'accesso.

Per ulteriori informazioni sulla concessione dei ruoli negli account di servizio, consulta Gestione dell'impersonificazione degli account di servizio.

Il ruolo Utente account di servizio

Puoi concedere il ruolo Utente account di servizio (roles/iam.serviceAccountUser) a livello di progetto per tutti gli account di servizio nel progetto o a livello di account di servizio.

  • La concessione del ruolo Utente account di servizio a un utente per un progetto consente all'utente di accedere a tutti gli account di servizio nel progetto, inclusi gli account di servizio che potrebbero essere creati in futuro.

  • La concessione del ruolo Utente account di servizio a un utente per un account di servizio specifico consente all'utente di accedere solo a tale account di servizio.

Le autorizzazioni di questo ruolo includono l'autorizzazione iam.serviceAccounts.actAs. Di conseguenza, gli utenti a cui è stato concesso il ruolo Utente account di servizio su un account di servizio possono utilizzarlo per accedere indirettamente a tutte le risorse a cui ha accesso l'account di servizio. Ad esempio, se a un account di servizio è stato concesso il ruolo Amministratore Compute (roles/compute.admin), un utente a cui è stato concesso il ruolo Utenti account di servizio (roles/iam.serviceAccountUser) su tale account di servizio può agire come all'account di servizio per avviare un'istanza Compute Engine. In questo flusso, l'utente impersona l'account di servizio per eseguire qualsiasi attività utilizzando i ruoli e le autorizzazioni concessi.

Per ulteriori informazioni sulla concessione dei ruoli utente agli account di servizio, consulta Gestione dell'impersonificazione degli account di servizio.

Gli account di servizio rappresentano la sicurezza a livello di servizio. La sicurezza del servizio è determinata dalle persone che hanno i ruoli IAM per gestire e utilizzare gli account di servizio e dalle persone che hanno le chiavi dell'account di servizio per questi account di servizio. Le best practice per garantire la sicurezza includono quanto segue:

  • Utilizzare l'API IAM per controllare gli account di servizio, le chiavi e i criteri di autorizzazione per tali account di servizio.
  • Se i tuoi account di servizio non hanno bisogno di chiavi degli account di servizio, disattivali o eliminali.
  • Se gli utenti non hanno bisogno dell'autorizzazione per gestire o utilizzare gli account di servizio, rimuovili dal criterio di autorizzazione applicabile.
  • Assicurati che gli account di servizio abbiano il minor numero di autorizzazioni possibile. Utilizza con attenzione gli account di servizio predefiniti, perché a questi viene concesso automaticamente il ruolo Editor (roles/editor) per il progetto.

Per scoprire di più sulle best practice, consulta Best practice per l'utilizzo degli account di servizio.

Ruolo di Creatore token account di servizio

Questo ruolo consente alle entità di impersonare account di servizio per:

  • Creare token di accesso OAuth 2.0 da utilizzare per l'autenticazione con le API di Google
  • Creazione di token ID OpenID Connect (OIDC)
  • Firma token web JSON (JWT) e blob binari in modo che possano essere utilizzati per l'autenticazione

Per i dettagli, consulta Creazione delle credenziali dell'account di servizio di breve durata.

Le autorizzazioni del ruolo includono:

  • iam.serviceAccounts.getAccessToken: consente di creare token di accesso OAuth 2.0
  • iam.serviceAccounts.getOpenIdToken: consente di creare token ID OpenID Connect (OIDC)
  • iam.serviceAccounts.implicitDelegation: consente agli account di servizio di ricevere token in una catena di delega
  • iam.serviceAccounts.signBlob: consente di firmare blob binari
  • iam.serviceAccounts.signJwt: ti consente di firmare i JWT.

Ruolo utente di Workload Identity

Questo ruolo consente alle entità di impersonare account di servizio dei carichi di lavoro GKE.

Le autorizzazioni del ruolo includono:

  • iam.serviceAccounts.getAccessToken: consente di creare token di accesso OAuth 2.0
  • iam.serviceAccounts.getOpenIdToken: consente di creare token ID OpenID Connect (OIDC)

Ambiti di accesso

Gli ambiti di accesso sono un metodo legacy per specificare le autorizzazioni per un'istanza di macchina virtuale (VM) Compute Engine. Definiscono gli ambiti OAuth predefiniti utilizzati nelle richieste dell'interfaccia a riga di comando gcloud e delle librerie client.

Google Cloud ora utilizza IAM, non ambiti di accesso, per specificare le autorizzazioni per le istanze Compute Engine. Tuttavia, devi comunque impostare un ambito di accesso quando configuri un'istanza per impersonare un account di servizio.

Per ulteriori informazioni, consulta la documentazione di Compute Engine.

Credenziali dell'account di servizio di breve durata

Puoi creare credenziali di breve durata che ti consentono di assumere l'identità di un account di servizio Google Cloud. Queste credenziali possono essere utilizzate per autenticare le chiamate alle API Google Cloud o altre API non Google.

Il caso d'uso più comune per queste credenziali è la delega temporanea dell'accesso alle risorse Google Cloud in progetti, organizzazioni o account diversi. Ad esempio, anziché fornire a un chiamante esterno le credenziali permanenti di un account di servizio con privilegi elevati, puoi concedere l'accesso di emergenza temporaneo. In alternativa, un account di servizio designato con meno autorizzazioni può essere rappresentato da un chiamante esterno senza richiedere le credenziali di un account di servizio con privilegi più elevati.

Per saperne di più, consulta Creazione delle credenziali dell'account di servizio di breve durata.

Federazione delle identità per i carichi di lavoro

Puoi concedere le identità da un carico di lavoro eseguito all'esterno di Google Cloud, ad esempio su Amazon Web Services (AWS) o Microsoft Azure, la possibilità di impersonare un account di servizio. Ciò consente di accedere direttamente alle risorse utilizzando credenziali di breve durata, anziché utilizzare una chiave dell'account di servizio.

Per saperne di più, vedi Federazione delle identità per i carichi di lavoro.

Credenziali predefinite dell'applicazione

Credenziali predefinite dell'applicazione è uno strumento che le librerie client di Google Cloud utilizzano per rilevare automaticamente le credenziali degli account di servizio. Puoi specificare una chiave dell'account di servizio in una variabile di ambiente e le credenziali predefinite dell'applicazione utilizzano automaticamente quella chiave dell'account di servizio. Se non specifichi una chiave, le Credenziali predefinite dell'applicazione utilizzano l'account di servizio associato alla risorsa che esegue il codice o l'account di servizio predefinito per il servizio che esegue il codice.

Per scoprire di più, vedi Trovare automaticamente le credenziali.

Tipi di chiavi per gli account di servizio

Ogni account di servizio è associato a una coppia di chiavi RSA pubblica/privata. L'API Service Account Credentials utilizza questa coppia di chiavi interna per creare credenziali per gli account di servizio di breve durata e per firmare i blob e i token web JSON (JWT). Questa coppia di chiavi è nota come coppia di chiavi gestita da Google.

Inoltre, puoi creare più coppie di chiavi RSA pubbliche/private, note come coppie di chiavi gestite dall'utente, e utilizzare la chiave privata per l'autenticazione con le API di Google. Questa chiave privata è nota come chiave dell'account di servizio.

Coppie di chiavi gestite da Google

Le coppie di chiavi gestite da Google vengono utilizzate dall'API Service Account Credentials e dai servizi Google Cloud come App Engine e Compute Engine per generare credenziali di breve durata per gli account di servizio.

Le coppie di chiavi gestite da Google vengono ruotate e utilizzate automaticamente per la firma per un massimo di due settimane. Il processo di rotazione è probabile; l'utilizzo della nuova chiave aumenterà e diminuirà gradualmente durante il ciclo di vita della chiave.

La chiave privata in una coppia di chiavi gestita da Google viene sempre conservata in deposito a garanzia e non è possibile accedervi direttamente.

La chiave pubblica in una coppia di chiavi gestita da Google è accessibile pubblicamente, in modo che chiunque possa verificare le firme create con la chiave privata. Puoi accedere alla chiave pubblica in diversi formati:

  • Certificato X.509: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
  • Chiave web JSON (JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
  • Formato non elaborato: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Se scarichi e memorizzi nella cache la chiave pubblica, ti consigliamo di memorizzarla nella cache per un massimo di 24 ore per assicurarti di disporre sempre della chiave corrente. Indipendentemente da quando recuperi la chiave pubblica, questa sarà valida per almeno 24 ore dopo averla recuperata.

Coppie di chiavi gestite dagli utenti

Puoi creare coppie di chiavi gestite dall'utente per un account di servizio e poi utilizzare la chiave privata di ciascuna coppia per eseguire l'autenticazione con le API di Google. Questa chiave privata è nota come chiave dell'account di servizio.

Ogni account di servizio può avere fino a 10 chiavi. Google archivia solo la parte pubblica di una coppia di chiavi gestita dall'utente.

Esistono diversi modi per creare una coppia di chiavi gestita dall'utente per un account di servizio:

Le chiavi gestite dagli utenti sono credenziali importantissime. Per limitare l'uso delle chiavi gestite dagli utenti, puoi applicare i seguenti vincoli dei criteri dell'organizzazione in un'organizzazione, un progetto o una cartella:

  • constraints/iam.disableServiceAccountKeyCreation: impedisce alle entità di creare chiavi dell'account di servizio gestite dall'utente.
  • constraints/iam.disableServiceAccountKeyUpload: impedisce alle entità di caricare una chiave pubblica per un account di servizio.

Se applichi questi vincoli perché utilizzi la federazione delle identità per i carichi di lavoro, valuta la possibilità di utilizzare i vincoli dei criteri dell'organizzazione per la federazione delle identità per i carichi di lavoro per specificare quali provider di identità sono consentiti.

Passaggi successivi

Provalo

Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

Inizia gratuitamente