Sfondo

Un account di servizio è un tipo speciale di account Google destinato a rappresentare un utente non umano che deve autenticarsi ed essere autorizzato ad accedere ai dati nelle API di Google.

Tipicamente, gli account di servizio sono usati in scenari come:

• Esecuzione di carichi di lavoro su macchine virtuali (VM).
• Esecuzione di carichi di lavoro su stazioni di lavoro in loco o centri dati che chiamano le API di Google.
• Esecuzione di carichi di lavoro che non sono legati al ciclo di vita di un utente umano.

La tua applicazione assume l’identità dell’account di servizio per chiamare le API di Google, in modo che gli utenti non siano direttamente coinvolti.

Gestire gli account di servizio

Una volta deciso che hai bisogno di un account di servizio, puoi farti le seguenti domande per capire come userai l’account di servizio:

• A quali risorse può accedere l’account di servizio?
• Di quali permessi ha bisogno l’account di servizio?
• Dove verrà eseguito il codice che assume l’identità dell’account di servizio: su Google Cloud o in locale?

Utilizza il seguente diagramma di flusso per capire le risposte alle domande precedenti:

Nota che i service account possono essere pensati sia come fonte che come identità.

Quando si pensa all’account di servizio come a un’identità, si può concedere un ruolo all’account di servizio, permettendogli di accedere a una risorsa (come un progetto).

Quando si pensa all’account di servizio come a una risorsa, si possono concedere ruoli ad altri utenti per accedere o gestire quell’account di servizio.

Garantire l’accesso agli account di servizio

Garantire l’accesso a un account di servizio per accedere a una risorsa è simile alla concessione di accesso a qualsiasi altra identità. Per esempio, se si ha un’applicazione in esecuzione su Compute Engine e si vuole che l’applicazione abbia accesso solo alla creazione di oggetti in Cloud Storage. Il seguente diagramma illustra questo esempio:

Learn aboutGranting roles to all types of members,including service accounts.

Tenere traccia degli account di servizio

Con il tempo, quando crei sempre più account di servizio, potresti perdere traccia di quale account di servizio è usato per quale scopo.

Il nome visualizzato di un account di servizio è un buon modo per catturare informazioni aggiuntive sull’account di servizio, come lo scopo dell’account di servizio o una persona di contatto per l’account. Per i nuovi account di servizio, puoi inserire il nome visualizzato quando crei l’account di servizio. Per gli account di servizio esistenti usa il metodo serviceAccounts.update() per modificare il nome visualizzato.

Identificare gli account di servizio inutilizzati

Gli account di servizio inutilizzati creano un rischio inutile per la sicurezza, quindi si consiglia di disabilitare gli account di servizio inutilizzati e di cancellarli quando si è sicuri di non averne più bisogno. Puoi usare i seguenti metodi per identificare gli account di servizio inutilizzati:

• Gli approfondimenti sugli account di servizio ti dicono quali account di servizio nel tuo progetto non si sono autenticati negli ultimi 90 giorni.
• Le metriche di utilizzo degli account di servizio ti permettono di controllare quando un account di servizio è stato usato l’ultima volta.

Eliminare e ricreare gli account di servizio

È possibile eliminare un account di servizio e poi creare un nuovo account di servizio con lo stesso nome.

Quando si elimina un account di servizio, i suoi role binding non vengono immediatamente eliminati. Invece, i legami di ruolo elencano l’account di servizio con il prefissodeleted:. Per un esempio, vedi Politiche con membri cancellati.

Se crei un nuovo account di servizio con lo stesso nome di un account di servizio recentemente eliminato, i vecchi binding possono ancora esistere; tuttavia, non si applicheranno 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 dato un ID unico in Identity and Access Management (IAM) al momento della creazione. Internamente, tutti i legami di ruolo sono concessi utilizzando questi ID, non l’indirizzo email dell’account di servizio. Pertanto, tutti i legami di ruolo che esistevano per un account di servizio eliminato non si applicano a un nuovo account di servizio che utilizza lo stesso indirizzo e-mail.

Similmente, se si collega un account di servizio a una risorsa, poi si elimina l’account di servizio e si crea un nuovo account di servizio con lo stesso nome, il nuovo account di servizio non sarà collegato alla risorsa.

Per prevenire questo comportamento inaspettato, considerare l’utilizzo di un nuovo nome unico per ogni account di servizio. Inoltre, se si elimina accidentalmente un account di servizio, si può tentare di annullare l’account di servizio invece di creare un nuovo account di servizio.

Se non è possibile annullare l’account di servizio originale e si deve creare un nuovo account di servizio con lo stesso nome e gli stessi ruoli, è necessario concedere i ruoli al nuovo account di servizio. Per i dettagli, vedi Politiche con membri cancellati.

Se hai anche bisogno che il nuovo account di servizio sia collegato alle stesse risorse dell’account di servizio originale, fai una delle seguenti cose:

• Per le istanze di Compute Engine, puoi cambiare l’account di servizio collegato all’istanza per sostituire l’account di servizio originale con quello nuovo.
• Per tutte le altre risorse, è necessario eliminare la risorsa esistente, quindi creare una nuova risorsa dello stesso tipo e collegare il nuovo account di servizio.

Permessi per gli account di servizio

Questa sezione descrive gli scenari comuni per i permessi concessi agli account di servizio, o agli account utente che hanno il permesso di impersonare gli account di servizio:

• Garantire i permessi minimi agli account di servizio
• I permessi degli account di servizio per scenari comuni

Garantire i permessi minimi agli account di servizio

Come per tutti i tipi di membri, dovresti concedere all’account di servizio solo l’insieme minimo di permessi richiesti per raggiungere il suo obiettivo. Impara a concedere i ruoli a tutti i tipi di membri, inclusi gli account di servizio.

Quando concedi i permessi agli utenti per accedere a un account di servizio, tieni a mente che l’utente può accedere a tutte le risorse per le quali l’account di servizio ha i permessi. Perciò è importante configurare attentamente i permessi dei tuoi account di servizio; cioè, sii rigoroso su chi nel tuo team può agire come (o impersonare) un account di servizio. Usare particolare cautela quando si permette agli utenti di impersonare account di servizio altamente privilegiati, come gli account di servizio di default di Compute Engine e App Enginedefault.

Gli utenti con ruoli IAM per aggiornare le istanze di App Engine e Compute Engine (comeApp Engine Deployer o Compute Instance Admin) possono effettivamente eseguire codice come gli account di servizio usati per eseguire queste istanze, e indirettamente ottenere l’accesso a tutte le risorse per cui gli account di servizio hanno accesso. Allo stesso modo, l’accesso SSH a un’istanza di Compute Engine può anche fornire la possibilità di eseguire codice come quell’istanza.

Permessi degli account di servizio per scenari comuni

Gli account di servizio possono essere usati in molti scenari diversi e ognuno di essi richiede determinati permessi. Questa sezione descrive gli scenari comuni e quali permessi sono richiesti.

Attaccare gli account di servizio alle risorse

Se vuoi avviare un lavoro di lunga durata che si autentica come un account di servizio, devi attaccare un account di servizio alla risorsa che eseguirà il lavoro.

Permessi:

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

Per trovare i ruoli che includono questi permessi, cerca nell’elenco dei ruoli i permessi.

Ci sono diverse risorse Google Cloud che possono eseguire lavori di lunga durata come account di servizio. Alcuni esempi di queste risorse includono:

• Macchine virtuali del motore di calcolo
• App Engine apps
• Funzioni cloud

Quando si creano queste risorse, si ha la possibilità di allegare un account di servizio. Questo account di servizio funge da identità della risorsa.

Per creare una risorsa e allegare un account di servizio, hai bisogno dei permessi per creare quella risorsa e il permesso di impersonare l’account di servizio che allegherai alla risorsa. Il permesso di impersonare l’account di servizio è fornito da qualsiasi ruolo che include il permesso iam.serviceAccounts.actAs.

Dopo aver creato la risorsa e collegato un account di servizio ad essa, puoi avviare un lavoro a lungo termine sulla risorsa. Il lavoro viene eseguito come l’account di servizio collegato alla risorsa e usa quell’account di servizio per autorizzare le richieste alle API di Google Cloud.

Per saperne di più su come collegare gli account di servizio alle risorse, vediAggiungi un account di servizio a una risorsa.

Impersonare direttamente un account di servizio

Permessi:

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

Ruolo:

• roles/iam.serviceAccountTokenCreator (Service Account Token Creator)

Una volta concessi i permessi richiesti, un utente (o servizio) può direttamente impersonare (o affermare) l’identità di un account di servizio in alcuni scenari comuni.

In primo luogo, l’utente può ottenere credenziali a breve termine per l’account del servizio usando il permessoiam.serviceAccounts.getAccessToken e chiamando il metodogenerateAccessToken(). Utilizzando le credenziali a breve termine, un utente può impartire comandi a Google Cloud e può accedere a tutte le risorse a cui l’account di servizio ha accesso. Per esempio, questo flusso permette a un utente di usare il flaggcloud --impersonate-service-account per impersonare l’account di servizio senza richiedere l’uso di una chiave esterna scaricata dell’account di servizio.

In secondo luogo, l’utente può ottenere artefatti firmati dalla chiave privata gestita da Google dell’account di servizio usando il permesso iam.serviceAccounts.signBlob e chiamando il metodosignBlob()osignJwt(). La chiave privata gestita da Google è sempre tenuta in garanzia e non è mai esposta direttamente. signBlob() permette la firma di payload arbitrari (come gli URL firmati da Cloud Storage), mentre signJwt() permette solo la firma di JWT ben formati.

Infine, l’utente può impersonare (o asserire) l’account del servizio senza mai recuperare una credenziale per l’account del servizio. Questo è un caso d’uso avanzato ed è supportato solo per l’accesso programmatico usando il metodogenerateAccessToken(). In scenari con almeno 3 account di servizio, cioè A, B e C: l’account di servizio A può ottenere un token di accesso per l’account di servizio C se all’account di servizio A è concesso il permessoiam.serviceAccounts.implicitDelegation su B, e a B è concesso il permesso iam.serviceAccounts.getAccessToken su C.

Generazione di token ID OpenID Connect (OIDC)

Permessi:

• iam.serviceAccounts.getOpenIdToken

Ruoli:

• roles/iam.serviceAccountTokenCreator (Service Account Token Creator)

Un utente (o servizio) può generare un token JWT compatibile con OpenID Connect (OIDC) firmato dal Google OIDC Provider (accounts.google.com) che rappresenta l’identità dell’account del servizio utilizzando la iam.serviceAccounts.getOpenIdTokenpermissione.

Questi token non sono direttamente accettati dalla maggior parte delle API di Google senza che la tua organizzazione distribuisca un’ulteriore federazione di identità per garantire l’accesso a Google. Ci sono alcune eccezioni-per esempio, Identity-Aware Proxy, che permette l’accesso basato su OIDC alle applicazioni gestite dagli utenti.

Generazione di chiavi private esterne

Permissioni:

• iam.serviceAccountKeys.create

Ruolo:

• roles/editor (Editor)
• roles/iam.serviceAccountAdmin (Service Account Admin)

Un utente o un servizio può generare una chiave privata esterna (RSA) che può essere usata per autenticarsi direttamente a Google come account del servizio. Questo materiale chiave può poi essere usato con le librerie Application Default Credentials (ADC), o con il comandogcloud auth activate-service-account. Qualsiasi persona che ottiene l’accesso al materiale della chiave avrà poi pieno accesso a tutte le risorse a cui l’account di servizio ha accesso. Tale materiale a chiave privata dovrebbe essere trattato con la massima preoccupazione, e dovrebbe essere considerato meno sicuro quanto più a lungo il materiale esiste. Pertanto, la rotazione del materiale della chiave privata è fondamentale per mantenere una forte sicurezza.

Gestione delle chiavi degli account di servizio

Ci sono due tipi di chiavi per account di servizio:

• chiavi gestite da Google Cloud. Queste chiavi sono usate da Google Cloudservices come App Engine e Compute Engine. Non possono essere scaricate e sono automaticamente ruotate e utilizzate per la firma per un massimo di due settimane. Il processo di rotazione è probabilistico; l’uso della nuova chiave aumenterà e diminuirà gradualmente durante la vita della chiave. Raccomandiamo di memorizzare il set di chiavi pubbliche per un account di servizio per un massimo di 24 ore per assicurarsi di avere sempre accesso all’attuale set di chiavi.

• Chiavi gestite dall’utente. Queste chiavi sono create, scaricabili e gestite dagli utenti. Dopo averle eliminate dall’account di servizio, non è possibile utilizzarle per autenticarsi.

Per le chiavi gestite dall’utente, devi assicurarti di avere processi in atto per affrontare i requisiti di gestione delle chiavi come:

• Conservazione delle chiavi
• Distribuzione delle chiavi
• Revoca delle chiavi
• Rotazione delle chiavi
• Protezione delle chiavi da utenti non autorizzati
• Recupero delle chiavi

Chiunque abbia accesso a una chiave privata valida per un account di servizio potrà accedere alle risorse attraverso l’account di servizio. Si noti che il ciclo di vita dell’accesso della chiave all’account di servizio (e quindi, i dati a cui l’account di servizio ha accesso) è indipendente dal ciclo di vita dell’utente che ha scaricato la chiave.

Scoraggiate sempre gli sviluppatori dal controllare le chiavi nel codice sorgente o dal lasciarle nella directory Download della loro postazione di lavoro.

Per migliorare la sicurezza delle chiavi, seguite la guida seguente:

• Utilizzate l’API dell’account di servizio IAM per ruotare automaticamente le chiavi degli account di servizio. Puoi ruotare una chiave creando una nuova chiave, cambiando le applicazioni per usare la nuova chiave e poi cancellando la vecchia chiave. Usa i metodi serviceAccount.keys.create()e serviceAccount.keys.delete() insieme per automatizzare la rotazione. Le chiavi gestite da Google Cloud vengono ruotate circa una volta alla settimana.

  • Utilizza il metodo serviceAccount.keys.list() per controllare gli account di servizio e le chiavi.

Usare gli account di servizio con Compute Engine

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

• Puoi creare VM nello stesso progetto con diversi account di servizio. Per cambiare l’account di servizio di una VM dopo la sua creazione, usa il metodoinstances.setServiceAccount.

• Puoi assegnare ruoli IAM agli account di servizio per definire a cosa possono accedere. In molti casi non avrete più bisogno di fare affidamento sugli ambiti. Questo ti dà il vantaggio di poter modificare i permessi dell’account di servizio di unaVM senza ricreare l’istanza.

• Siccome le istanze dipendono dai loro account di servizio per avere accesso alle risorse di 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 fallire le loro operazioni.

Best practices

• Specifica chi può agire come account di servizio. Gli utenti che sono utenti di account di servizio per un account di servizio possono accedere indirettamente a tutte le risorse a cui l’account di servizio ha accesso. Pertanto, sii cauto quando concedi il ruolo theserviceAccountUser a un utente.

• Dona all’account di servizio solo l’insieme minimo di permessi richiesti per raggiungere il suo obiettivo. Impara a concedere ruoli a tutti i tipi di membri, inclusi gli account di servizio.

• Crea account di servizio per ogni servizio con solo i permessi richiesti per quel servizio.

• Usa il nome visualizzato di un account di servizio per tenere traccia degli account di servizio. Quando crei un account di servizio, inserisci il suo nome visualizzato con lo scopo dell’account di servizio.

• Definisci una convenzione di denominazione per i tuoi account di servizio.

• Implementa processi per automatizzare la rotazione delle chiavi degli account di servizio gestiti dagli utenti.

• Sfrutta l’API degli account di servizioIAM per implementare la rotazione delle chiavi.

• Controlla gli account di servizio e le chiavi usando il metodoserviceAccount.keys.list() o la pagina del visualizzatore di log nella console.

• Non cancellare gli account di servizio che sono in uso da istanze in esecuzione suApp Engine o Compute Engine a meno che tu non voglia che queste applicazioni perdano l’accesso all’account di servizio.