Account di servizio

In questa pagina vengono descritti gli account di servizio, i tipi di account di servizio e i ruoli IAM disponibili per gli account di servizio.

Prima di iniziare

  • Comprendi i concetti di base di IAM.

Che cosa sono gli account di servizio?

Un account di servizio è un tipo speciale 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. Le applicazioni utilizzano gli account di servizio per effettuare chiamate API autorizzate, 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 associato a una VM di Compute Engine, in modo che le applicazioni in esecuzione su tale VM possano eseguire l'autenticazione come account di servizio. Inoltre, all'account di servizio possono essere assegnati ruoli IAM che 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 l'applicazione.

Un account di servizio è identificato dal suo indirizzo email, univoco per l'account.

Differenze tra un account di servizio e un account utente

Gli account di servizio differiscono dagli account utente per alcuni aspetti principali:

  • Gli account di servizio non hanno password e non possono accedere tramite browser o cookie.
  • Gli account di servizio sono associati alle coppie di chiavi RSA pubbliche/private utilizzate per l'autenticazione in Google e 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, come documenti o eventi, con l'intero dominio Google Workspace 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, i tuoi amministratori di Google Workspace e Cloud Identity non possono possedere o gestire questi asset.

Impedire la creazione di account di servizio

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

Prima di applicare questo vincolo, tieni presente le seguenti limitazioni:

Account di servizio e gruppi Google

Puoi aggiungere account di servizio a un gruppo Google, quindi concedere ruoli al gruppo. Tuttavia, aggiungere account di servizio ai gruppi non è una best practice. Gli account di servizio vengono utilizzati dalle applicazioni e è probabile che ogni applicazione abbia i propri requisiti di accesso.

Tipi di chiavi per gli account di servizio

Ogni account di servizio è associato a una coppia di chiavi pubblica/privata RSA. L'API Service Account Credentials utilizza questa coppia di chiavi interna per creare credenziali di account di servizio di breve durata e per firmare blob e 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 dagli utenti, 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 è probabilistica; l'utilizzo della nuova chiave aumenterà e diminuirà gradualmente nel corso della durata della chiave.

La chiave privata in una coppia di chiavi gestita da Google è sempre conservata a garanzia e non è mai accessibile.

La chiave pubblica in una coppia di chiavi gestita da Google è accessibile pubblicamente, in modo che tutti possano 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 al massimo per 24 ore per assicurarti di avere sempre la chiave corrente. Indipendentemente dal momento in cui recupera la chiave pubblica, questa sarà valida per almeno 24 ore dopo il recupero.

Coppie di chiavi gestite dall'utente

Puoi creare coppie di chiavi gestite dagli utenti per un account di servizio, quindi utilizzare la chiave privata di ogni coppia di chiavi 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 dell'account di servizio. Google memorizza 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: se non vengono gestite correttamente, possono rappresentare un grave rischio per la sicurezza. 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 i provider di identità consentiti.

Specificare una scadenza per le chiavi gestite dagli utenti

Per impostazione predefinita, quando crei una chiave dell'account di servizio gestita dall'utente, la chiave non scade mai. Puoi modificare questa impostazione predefinita impostando una data di scadenza per tutte le nuove chiavi create nel progetto, nella cartella o nell'organizzazione.

Utilizza i tempi di scadenza quando hai bisogno di accedere temporaneamente a un sistema, soprattutto se quest'ultimo richiede una chiave di account di servizio. Ad esempio, utilizza i tempi di scadenza in questi scenari:

  • Uno sviluppatore deve completare un codelab che richiede chiavi dell'account di servizio.
  • Uno sviluppatore deve eseguire uno strumento dell'interfaccia a riga di comando che richiede una chiave dell'account di servizio.
  • I dipendenti temporanei, ad esempio stagisti o collaboratori, stanno creando una proof of concept per una nuova domanda.

Evita di utilizzare scadenze per questi scenari:

  • Carichi di lavoro di produzione. In produzione, una chiave dell'account di servizio scaduta potrebbe causare un'interruzione accidentale. Utilizza invece chiavi che non scadono e gestisci il loro ciclo di vita con la rotazione.
  • I carichi di lavoro non di produzione che richiedono l'accesso permanente, ad esempio una pipeline di integrazione continua (CI).

Per impostare una scadenza, utilizza Impostazioni risorsa per aggiornare l'impostazione settings/iam-serviceAccountKeyExpiry. Dopo aver aggiornato questa impostazione per il progetto, la cartella o l'organizzazione, la data di scadenza si applica a tutte le nuove chiavi dell'account di servizio create all'interno della risorsa principale. Le chiavi esistenti non sono interessate.

Per maggiori dettagli su questa impostazione, consulta l'indice delle impostazioni delle risorse. Per informazioni su come aggiornare l'impostazione, consulta Modificare un valore di un'impostazione locale.

Come best practice, utilizza scadenze brevi come 8hours, 24hours o 7days. I tempi di scadenza brevi consentono di garantire che il tuo team abbia una procedura ben testata per l'aggiornamento delle chiavi. Inizia con la scadenza più breve che soddisfa le tue esigenze e aumentala solo se necessario.

Tipi di account di servizio

Account di servizio gestiti dall'utente

Puoi creare account di servizio gestiti dagli utenti nel tuo progetto utilizzando l'API IAM, Cloud Console o l'interfaccia a riga di comando di Google Cloud. L'utente è responsabile della gestione e della protezione di 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 Cloud Console 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 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, vengono creati account di servizio gestiti dall'utente che consentono al servizio di eseguire il deployment di job che accedono ad altre risorse 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, può utilizzare le credenziali di 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 informazioni dettagliate, vedi Trovare automaticamente le credenziali.

La tabella seguente elenca 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 hanno bisogno di accedere alle tue 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 di servizio sono noti come account di servizio gestiti da Google. Potresti vedere gli account di servizio gestiti da Google nei criteri di autorizzazione del progetto, nei log di controllo o nella pagina IAM di Cloud Console.

Gli account di servizio gestiti da Google non sono elencati nella pagina Account di servizio di Cloud Console.

Ad esempio:

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

    Questo account di servizio esegue i processi interni di Google per tuo conto. Il ruolo Editor (roles/editor) viene concesso automaticamente per il 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. A questi agenti di servizio potrebbero essere concessi automaticamente dei ruoli; di solito i nomi di questi ruoli terminano con serviceAgent.

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

  • Gestore dei ruoli per gli account di servizio gestiti da Google. I tuoi 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 associato al progetto. La concessione di questi ruoli genera una voce di log di controllo, che indica che service-agent-manager@system.gserviceaccount.com ha impostato il criterio di autorizzazione per il progetto.

Località degli 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 consente di iniziare a utilizzare facilmente gli account di servizio. Tuttavia, può essere difficile tenere traccia degli account di servizio quando sono distribuiti in molti progetti.

  • Centralizza gli account di servizio in progetti separati.

    Questo approccio inserisce tutti gli account di servizio per l'organizzazione in un numero ridotto di progetti, semplificando la gestione degli account. Tuttavia, richiede la configurazione aggiuntiva se colleghi account di servizio alle risorse in altri progetti, il che consente a tali risorse di utilizzare l'account di servizio come propria 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 in my-service-accounts e 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, 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.

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 principali 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) sull'account di servizio.

Per ulteriori informazioni sulla concessione dei ruoli alle entità, inclusi gli account di servizio, consulta Concessione, modifica e revoca dell'accesso.

Per ulteriori informazioni sulla concessione dei ruoli negli account di servizio, consulta la sezione Gestire l'impersonificazione degli account di servizio.

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 del progetto, inclusi gli account di servizio che potrebbero essere creati in futuro.

  • Se concedi il ruolo Utente account di servizio a un utente per un account di servizio specifico, l'utente potrà accedere soltanto a quell'account di servizio.

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 questo account. 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 dell'account di servizio (roles/iam.serviceAccountUser) su tale account può agire come 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 negli account di servizio, consulta la sezione Gestire l'impersonificazione degli account di servizio.

Gli account di servizio rappresentano la sicurezza del livello di servizio. La sicurezza del servizio è determinata dalle persone che hanno ruoli IAM per gestire e utilizzare gli account di servizio e dalle persone che contengono chiavi esterne private per tali account. Le best practice per garantire la sicurezza includono:

  • Utilizza 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 esterne, eliminale.
  • 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 dispongano del numero minimo di autorizzazioni possibile. Utilizza con cautela gli account di servizio predefiniti, perché viene loro concesso automaticamente il ruolo Editor (roles/editor) nel progetto.

Per scoprire di più sulle best practice, consulta l'articolo Informazioni sugli account di servizio.

Ruolo Creatore token account di servizio

Questo ruolo consente la rappresentazione degli account di servizio per creare token di accesso OAuth2, blob di firma o JWT.

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 gli 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 presumere l'identità di un account di servizio Google Cloud. Le credenziali possono essere utilizzate per autenticare le chiamate alle API Google Cloud o ad altre API non Google.

Il caso d'uso più comune di queste credenziali è la delega temporanea dell'accesso alle risorse Google Cloud tra 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 temporaneo in caso di emergenza. 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 ulteriori informazioni, consulta Creazione di credenziali di un account di servizio di breve durata.

Federazione delle identità per i carichi di lavoro

Puoi concedere identità da un carico di lavoro eseguito al di fuori di Google Cloud, come su Amazon Web Services (AWS) o Microsoft Azure, per impersonare un account di servizio. In questo modo puoi 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

Le credenziali predefinite dell'applicazione sono uno strumento che le librerie client di Google Cloud utilizzano per rilevare automaticamente le credenziali dell'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 collegato alla risorsa che esegue il tuo codice o l'account di servizio predefinito per il servizio che esegue il tuo codice.

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

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