Informazioni sugli account di servizio

Contesto

Un account di servizio è un tipo speciale di Account Google destinato a rappresentare un utente non umano che deve eseguire l'autenticazione e deve essere autorizzato ad accedere ai dati nelle API di Google.

In genere, gli account di servizio vengono utilizzati in scenari quali:

  • Esecuzione dei carichi di lavoro su macchine virtuali (VM).
  • Esecuzione di carichi di lavoro su workstation o data center on-premise che chiamano le API di Google.
  • Esecuzione di carichi di lavoro non legati al ciclo di vita di un utente umano.

L'applicazione presuppone l'identità dell'account di servizio per chiamare le API di Google, in modo che gli utenti non siano coinvolti direttamente.

Gestione degli account di servizio

Gli account di servizio possono essere considerati sia come risorsa sia come identità.

Quando consideri l'account di servizio come un'identità, puoi concedere un ruolo a un account di servizio per consentirgli di accedere a una risorsa (ad esempio, un progetto).

Quando pensi a un account di servizio come risorsa, puoi concedere ruoli ad altri utenti per accedervi o gestirlo.

Concessione dell'accesso agli account di servizio

La concessione dell'accesso a un account di servizio per accedere a una risorsa è simile a quella di accesso a qualsiasi altra identità. Ad esempio, se un'applicazione è in esecuzione su Compute Engine e vuoi che abbia l'accesso solo per creare oggetti in Cloud Storage, Puoi creare un account di servizio per l'applicazione e assegnargli il ruolo Creatore oggetti Storage.

Scopri di più sulla concessione di ruoli a tutti i tipi di entità, inclusi gli account di servizio.

Monitoraggio degli account di servizio

Nel tempo, man mano che crei sempre più account di servizio, potresti perdere il controllo di quale account di servizio viene utilizzato e il relativo scopo.

Il nome visualizzato di un account di servizio è un buon modo per acquisire ulteriori informazioni sull'account di servizio, ad esempio la finalità dell'account di servizio o un contatto per l'account. Per i nuovi account di servizio, è possibile compilare il nome visualizzato durante la creazione dell'account di servizio. Per gli account di servizio esistenti, utilizza il metodo serviceAccounts.update() per modificare il nome visualizzato.

Identificazione degli account di servizio non utilizzati

Gli account di servizio non utilizzati comportano un rischio di sicurezza superfluo, pertanto ti consigliamo di disattivare gli account di servizio non utilizzati, per poi eliminare gli account di servizio quando non ne hai più bisogno. Puoi utilizzare i seguenti metodi per identificare gli account di servizio inutilizzati:

Puoi anche utilizzare le metriche di utilizzo dell'account di servizio per tenere traccia dell'utilizzo delle chiavi e degli account di servizio in generale.

Eliminazione e nuova creazione di account di servizio

È possibile eliminare un account di servizio e crearne uno nuovo con lo stesso nome.

Quando elimini un account di servizio, le associazioni dei ruoli non vengono eliminate immediatamente. Le associazioni dei ruoli elencano invece l'account di servizio con il prefisso deleted:. Per un esempio, consulta Criteri con entità eliminate.

Se crei un nuovo account di servizio con lo stesso nome di un account di servizio eliminato di recente, le associazioni precedenti potrebbero comunque esistere, ma non verranno applicate al nuovo account di servizio anche se entrambi gli account hanno lo stesso indirizzo email. Questo comportamento si verifica perché agli account di servizio viene assegnato un ID univoco all'interno di Identity and Access Management (IAM) al momento della creazione. Internamente, tutte le associazioni di ruoli vengono concesse utilizzando questi ID, non l'indirizzo email dell'account di servizio. Pertanto, le associazioni dei ruoli esistenti per un account di servizio eliminato non si applicano a un nuovo account di servizio che utilizza lo stesso indirizzo email.

Allo stesso modo, se colleghi un account di servizio a una risorsa, quindi elimini l'account di servizio e crei un nuovo account di servizio con lo stesso nome, il nuovo account di servizio non verrà collegato alla risorsa.

Per evitare questo comportamento imprevisto, utilizza un nuovo nome univoco per ogni account di servizio. Inoltre, se elimini accidentalmente un account di servizio, puoi provare a annullare l'eliminazione dell'account di servizio anziché crearne uno nuovo.

Se non riesci ad annullare l'eliminazione dell'account di servizio originale e devi crearne uno nuovo con lo stesso nome e gli stessi ruoli, devi concedere i ruoli al nuovo account di servizio. Per maggiori dettagli, consulta Criteri con entità eliminate.

Se hai bisogno che il nuovo account di servizio venga collegato alle stesse risorse dell'account di servizio originale, esegui una delle seguenti operazioni:

Autorizzazioni per account di servizio

In questa sezione vengono descritti scenari comuni per le autorizzazioni concesse agli account di servizio o gli account utente che dispongono delle autorizzazioni necessarie per impersonare account di servizio:

Concessione delle autorizzazioni minime agli account di servizio

Come con tutti i tipi di entità, devi concedere all'account di servizio solo l'insieme minimo di autorizzazioni richieste per raggiungere l'obiettivo. Scopri di più sulla concessione di ruoli a tutti i tipi di entità, inclusi gli account di servizio.

Quando concedi le autorizzazioni agli utenti per accedere a un account di servizio, tieni presente che l'utente può accedere a tutte le risorse per le quali l'account di servizio dispone delle autorizzazioni. È quindi importante configurare con attenzione le autorizzazioni degli account di servizio; in questo caso, assicurati che il membro del tuo team possa agire (o impersonare) un account di servizio. Presta particolare attenzione quando consenti agli utenti di impersonare account di servizio con privilegi elevati, come Compute Engine e gli account di servizio predefiniti di App Engine.

Gli utenti con ruoli IAM per aggiornare le istanze di App Engine e Compute Engine (ad esempio App Engine Deployer o Compute Instance Admin) possono eseguire in modo efficace il codice come account di servizio utilizzati per eseguire queste istanze e accedere indirettamente a tutte le risorse a cui hanno accesso gli account di servizio. Allo stesso modo, l'accesso SSH a un'istanza di Compute Engine potrebbe anche offrire la possibilità di eseguire codice come istanza.

Autorizzazioni dell'account di servizio per scenari comuni

Gli account di servizio possono essere utilizzati in molti scenari diversi e ognuno richiede autorizzazioni specifiche. Questa sezione descrive scenari comuni e quali autorizzazioni sono necessarie.

Collegamento di account di servizio alle risorse

Se vuoi avviare un job a lunga esecuzione che esegue l'autenticazione come account di servizio, devi collegare un account di servizio alla risorsa che eseguirà il job.

Autorizzazioni:

  • Autorizzazioni per creare la risorsa
  • iam.serviceAccounts.actAs

Per trovare i ruoli che includono queste autorizzazioni, cerca l'elenco dei ruoli.

Esistono diverse risorse di Google Cloud che possono eseguire job a lunga esecuzione come account di servizio. Ecco alcuni esempi di risorse:

  • VM di Compute Engine
  • App di App Engine
  • Cloud Functions

Quando crei queste risorse, hai la possibilità di collegare un account di servizio. Questo account di servizio funge da identità della risorsa.

Per creare una risorsa e collegare un account di servizio, devi disporre delle autorizzazioni necessarie per crearla e impersonare l'account di servizio che applicherai alla risorsa. L'autorizzazione a impersonare l'account di servizio è fornita da qualsiasi ruolo che includa l'autorizzazione iam.serviceAccounts.actAs.

Dopo aver creato la risorsa e avervi collegato un account di servizio, puoi avviare un job a lunga esecuzione sulla risorsa. Il job viene eseguito come account di servizio associato alla risorsa e utilizza tale account di servizio per autorizzare le richieste alle API Google Cloud.

Per ulteriori informazioni su come collegare account di servizio alle risorse, vedi Collegamento di un account di servizio a una risorsa.

Furto d'identità diretto a un account di servizio

Autorizzazioni:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccounts.implicitDelegation

Ruoli:

  • roles/iam.serviceAccountTokenCreator (autore del token dell'account di servizio)

Una volta concesse le autorizzazioni richieste, un utente (o servizio) può impersonare direttamente (o rivendicare) l'identità di un account di servizio in alcuni scenari comuni.

Innanzitutto, l'utente può ricevere credenziali a breve termine per l'account di servizio utilizzando l'autorizzazione iam.serviceAccounts.getAccessToken e chiamando il metodo generateAccessToken(). Utilizzando credenziali a breve termine, un utente può inviare comandi a Google Cloud e accedere a tutte le risorse a cui ha accesso l'account di servizio. Ad esempio, questo flusso consente a un utente di utilizzare il flag gcloud --impersonate-service-account per impersonare l'account di servizio senza richiedere l'utilizzo di una chiave account di servizio esterna scaricata.

In secondo luogo, l'utente può ottenere gli artefatti firmati dalla chiave privata gestita da Google dell'account di servizio utilizzando l'autorizzazione iam.serviceAccounts.signBlob e chiamando il metodo signBlob() o signJwt(). La chiave privata gestita da Google è sempre tenuta a deposito e non viene mai esposta direttamente. signBlob() consente la firma di payload arbitrari (come gli URL firmati da Cloud Storage), mentre signJwt() consente solo la firma JWT con formato corretto.

Infine, l'utente può impersonare (o rivendicare) l'account di servizio senza mai recuperare una credenziale per l'account di servizio. Questo è un caso d'uso avanzato ed è supportato solo per l'accesso programmatico tramite il metodo generateAccessToken(). In scenari con almeno 3 account di servizio, vale a dire A, B e C: l'account di servizio A può ricevere un token di accesso per l'account di servizio C se all'account di servizio A viene concessa l'autorizzazione iam.serviceAccounts.implicitDelegation su B e a B viene concessa l'autorizzazione iam.serviceAccounts.getAccessToken su C.

Generazione di token ID OpenID Connect (OIDC)

Autorizzazioni:

  • iam.serviceAccounts.getOpenIdToken

Ruoli:

  • roles/iam.serviceAccountTokenCreator (autore del token dell'account di servizio)

Un utente (o servizio) può generare un token JWT compatibile con OpenID Connect (OIDC) firmato dal provider OIDC di Google (accounts.google.com) che rappresenta l'identità dell'account di servizio utilizzando l'autorizzazione iam.serviceAccounts.getOpenIdToken.

Questi token non sono accettati direttamente dalla maggior parte delle API di Google senza la tua organizzazione che esegue il deployment di una federazione delle identità aggiuntiva per concedere l'accesso a Google. Esistono alcune eccezioni, ad esempio Identity-Aware Proxy, che consente l'accesso basato su OIDC alle applicazioni eseguite dall'utente.

Generazione di chiavi private esterne

Autorizzazioni:

  • iam.serviceAccountKeys.create

Ruoli:

  • roles/editor (Editor)
  • roles/iam.serviceAccountKeyAdmin (amministratore chiave account di servizio)

Un utente o un servizio può generare materiale di chiave privata esterna (RSA) che può essere utilizzato per l'autenticazione direttamente con Google come account di servizio. Questo materiale delle chiavi potrà essere utilizzato con le librerie delle credenziali predefinite dell'applicazione (ADC) o con il comando gcloud auth activate-service-account. Chiunque abbia accesso al materiale della chiave avrà accesso completo a tutte le risorse a cui ha accesso l'account di servizio. Tale materiale con chiave privata deve essere considerato con il livello di sicurezza più elevato e deve essere considerato meno sicuro più a lungo. Pertanto, la rotazione del materiale delle chiavi private è fondamentale per mantenere una sicurezza elevata.

Utilizzo di account di servizio con Compute Engine

Le istanze di Compute Engine devono essere eseguite come account di servizio per avere accesso ad altre risorse Google Cloud. Per assicurarti che le tue istanze di Compute Engine siano più sicure, considera quanto segue:

  • Puoi creare VM nello stesso progetto con account di servizio diversi. Per cambiare l'account di servizio di una VM dopo la creazione, utilizza il metodo instances.setServiceAccount.

  • Puoi concedere ruoli IAM agli account di servizio per definire ciò a cui possono accedere. In molti casi non sarà più necessario utilizzare gli ambiti. Questo ti dà il vantaggio di poter modificare le autorizzazioni di un account di servizio VM senza dover ricreare l'istanza.

  • Poiché le istanze dipendono dai loro account di servizio per avere accesso alle risorse Google Cloud, evita di eliminare gli account di servizio quando sono ancora utilizzati dalle istanze in esecuzione. Se elimini gli account di servizio, le istanze potrebbero iniziare a causare i problemi.

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