Questa pagina spiega cosa sono i service account e descrive considerazioni importanti per la gestione dei service account in ogni fase del loro ciclo di vita.
Che cosa sono i service account?
Un account di servizio è un tipo speciale di account utilizzato in genere da un'applicazione o da un carico di lavoro di calcolo, come un'istanza di Compute Engine, anziché da una persona. Un account di servizio è identificato dal rispettivo indirizzo email, che è univoco per l'account.
Le applicazioni utilizzano i service account per effettuare chiamate API autorizzate autenticandosi come il account di servizio stesso o come utenti Google Workspace o Cloud Identity tramite la delega a livello di dominio. Quando un'applicazione si autentica come account di servizio, ha accesso a tutte le risorse a cui il account di servizio ha l'autorizzazione di accedere.
Il modo più comune per consentire a un'applicazione di autenticarsi come account di servizio è collegare un service account alla risorsa che esegue l'applicazione. Ad esempio, puoi collegare un account di servizio a un'istanza Compute Engine in modo che le applicazioni in esecuzione su quell'istanza possano autenticarsi come account di servizio. Poi, puoi concedere all'account di servizio ruoli IAM per consentire all'account di servizio e, per estensione, alle applicazioni sull'istanza di accedere alle risorse Google Cloud .
Esistono altri modi per consentire alle applicazioni di autenticarsi come service account oltre ad allegare un account di servizio. Ad esempio, puoi configurare la federazione delle identità per i workload per consentire ai workload esterni di autenticarsi come service account o creare una chiave service account e utilizzarla in qualsiasi ambiente per ottenere token di accesso OAuth 2.0.
Per saperne di più sull'autenticazione di account di servizio per le applicazioni, consulta Panoramica delle identità per i workload.
Anche le entità, come gli utenti e altri service account, possono autenticarsi come service account. Per ulteriori informazioni, vedi Rappresentazione dell'account di servizio in questa pagina.
Tipi di service account
In Google Cloudesistono diversi tipi di service account:
Service account gestiti dall'utente: service account che crei e gestisci. Questi service account vengono spesso utilizzati come identità per i carichi di lavoro.
Service account predefiniti: service account gestiti dall'utente che vengono creati automaticamente quando abiliti determinati servizi Google Cloud . Sei responsabile della gestione di questi service account.
Agenti di servizio: service account creati e gestiti da Google Cloude che consentono ai servizi di accedere alle risorse per tuo conto.
Per saperne di più sui diversi tipi di service account, consulta Tipi di service account.
Credenziali del service account
Le applicazioni e i principal si autenticano come account di servizio eseguendo una delle seguenti operazioni:
- Recupero delle credenziali di breve durata. In molti casi, ad esempio per gli account di servizio collegati e i comandi che utilizzano il flag
--impersonate-service-accountdella gcloud CLI, queste credenziali vengono ottenute automaticamente, quindi non devi crearle o gestirle personalmente. - Utilizzo di una chiave del account di servizio per firmare un JSON Web Token (JWT) e scambiarlo con un token di accesso. Poiché le chiavi dei account di servizio comportano un rischio per la sicurezza se non vengono gestite correttamente, dovresti scegliere un'alternativa più sicura alle account di servizio account ogni volta che è possibile.
Per scoprire di più sull'autenticazione di account di servizio, consulta Credenziali del service account.
Simulazione dell'identità dei service account
Quando un'entità autenticata, ad esempio un utente o un altro account di servizio, esegue l'autenticazione come account di servizio per ottenere le autorizzazioni del service account, questa operazione viene chiamata simulazione del account di servizio. L'impersonificazione di un account di servizio consente a un'entità autenticata di accedere a tutto ciò a cui può accedere ilaccount di serviziot. Solo le entità autenticate con le autorizzazioni appropriate possono impersonare i service account.
L'impersonificazione è utile quando vuoi modificare le autorizzazioni di un utente senza modificare i criteri Identity and Access Management (IAM). Ad esempio, puoi utilizzare l'impersonificazione per concedere temporaneamente a un utente un accesso con privilegi elevati o per verificare se un insieme specifico di autorizzazioni è sufficiente per un'attività. Puoi anche utilizzare l'impersonificazione per sviluppare localmente applicazioni che possono essere eseguite solo come service account o per autenticare applicazioni eseguite al di fuori di Google Cloud.
Per scoprire di più sull'impersonificazione del account di servizio, consulta Impersonificazione del service account.
Account di servizio e domini Google Workspace
Gli account di servizio non appartengono al tuo dominio Google Workspace, a differenza degli account utente. Se condividi asset Google Workspace, come documenti o eventi, con l'intero dominio Google Workspace, questi non vengono condivisi con gli account di servizio.
Gli account di servizio non possono essere proprietari di asset Google Workspace. Possono, tuttavia, creare asset in un Drive condiviso nel dominio. Gli asset creati in un Drive condiviso sono di proprietà della tua organizzazione e vengono gestiti da quest'ultima.
Autorizzazioni service account
I service account sono entità. Ciò significa che puoi concedere
ai service account l'accesso alle risorse Google Cloud . Ad esempio, puoi concedere a un account di servizio il ruolo Amministratore Compute (roles/compute.admin) in un progetto. In questo modo, il account di servizio potrà gestire le risorse Compute Engine
in quel progetto.
Tuttavia, i service account sono anche risorse. Ciò significa che puoi concedere ad altre entità l'autorizzazione ad accedere al account di servizio. Ad esempio,
puoi concedere a un utente il ruolo Utente account di servizio
(roles/iam.serviceAccountUser) in un service account per consentirgli di collegare
questo service account alle risorse. In alternativa, puoi concedere a un utente il ruolo Amministratore service account (roles/iam.serviceAccountAdmin) per consentirgli di visualizzare, modificare, disattivare ed eliminare il account di servizio.
Le sezioni seguenti descrivono come gestire i service account come entità e come risorse.
Service account come entità
Poiché i service account sono entità, puoi gestire l'accesso per i service account proprio come faresti per qualsiasi altra entità. Ad esempio, se vuoi
consentire all'account di servizio della tua 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. In alternativa, se vuoi assicurarti che il account di servizio di un'applicazione non possa modificare le norme IAM di un progetto, puoi utilizzare una norma di negazione per impedire al account di servizio di utilizzare l'autorizzazione resourcemanager.projects.setIamPolicy per quel progetto. Per scoprire
di più sulla gestione dell'accesso per i principal, consulta Accesso in
Google Cloud.
Puoi gestire l'accesso per singoli service account o per tutti i service account di un progetto, una cartella o un'organizzazione specifici. Quando gestisci l'accesso per gli account di servizio, utilizza i seguenti identificatori principal per fare riferimento agli account di servizio:
| Tipo di entità | Identificatore entità |
|---|---|
| Un account di servizio individuale |
Esempio: |
| Tutti i service account in un progetto |
Esempio: |
| Tutti gli account di servizio in tutti i progetti di una cartella |
Esempio: |
| Tutti gli account di servizio in tutti i progetti di un'organizzazione |
Esempio: |
Come per tutti i tipi di entità, devi concedere all'account di servizio solo il set minimo di autorizzazioni necessarie per raggiungere il suo obiettivo.
Se i service account in un progetto, una cartella o un'organizzazione specifici condividono requisiti, utilizza i set di entità account di servizio per concedere loro ruoli anziché utilizzare gruppi personalizzati.
Per scoprire come concedere ruoli alle entità, inclusi i service account, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.
Service account come risorse
Anche i service account sono risorse che possono avere criteri di autorizzazione propri. Di conseguenza, puoi consentire ad altre entità di accedere a un account di servizio concedendo loro un ruolo sul account di servizio o su una delle risorse padre del account di servizio. Ad esempio, per consentire a un utente di simulare l'identità di un service
account, puoi concedere all'utente il ruolo Creatore token account di servizio
(roles/iam.serviceAccountTokenCreator) nell'account di servizio.
Quando concedi un ruolo che consente a un utente di simulare l'identità di un account di servizio, tieni presente che l'utente può accedere a tutte le risorse a cui può accedere l'account di servizio. Fai attenzione quando consenti agli utenti di rappresentare service account con privilegi elevati, come i service account predefiniti di Compute Engine e App Engine.
Per ulteriori informazioni sui ruoli che puoi concedere alle entità nei service account, consulta Autorizzazioni dei service account.
Per scoprire come concedere a un'entità un ruolo su un account di servizio, consulta Gestire l'accesso ai service account.
Ciclo di vita del service account
Man mano che gestisci i tuoi progetti, probabilmente creerai, gestirai ed eliminerai molti account di servizio diversi. Questa sezione descrive le considerazioni chiave per la gestione dei service account nelle varie fasi del loro ciclo di vita.
Dove creare gli account di servizio
Ogni account di servizio si trova in un progetto. Una volta creato un account di servizio, non puoi più spostarlo in un altro progetto.
Esistono diversi modi per organizzare i service account in progetti:
Crea service account e risorse nello stesso progetto.
Questo approccio semplifica l'utilizzo dei service account. Tuttavia, può essere difficile tenere traccia dei tuoi service account quando sono distribuiti su molti progetti.
Centralizza i service account in progetti separati.
Questo approccio inserisce tutti i service account della tua organizzazione in un numero ridotto di progetti, il che può semplificare la gestione dei service account. Tuttavia, richiede una configurazione aggiuntiva se colleghi service account a risorse in altri progetti, il che consente a queste risorse di utilizzare il 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-accountse un'istanza Cloud SQL nel progettomy-application, devi abilitare l'API Cloud SQL sia inmy-service-accountsche inmy-application.Per impostazione predefinita, puoi creare fino a 100 service account in un progetto. Se devi creare altri service account, richiedi un aggiustamento della quota.
Per scoprire come creare un account di servizio, vedi Creare service account.
Impedire la creazione di service account
Per controllare meglio dove vengono creati gli account di servizio, potresti voler impedire la creazione di account di servizio in alcuni progetti della tua organizzazione.
Puoi impedire la creazione di service account applicando il
constraints/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:
Se applichi questo vincolo in un progetto o in tutti i progetti all'interno di un'organizzazione, alcuni servizi Google Cloud non possono creare service account predefiniti. Di conseguenza, se il progetto esegue workload che devono autenticarsi come service account, il progetto potrebbe non contenere uaccount di serviziont che il workload può utilizzare.
Per risolvere il problema, puoi abilitare la simulazione dell'identità degli account di servizio tra progetti. Quando abiliti questa funzionalità, puoi creare service account in un progetto centralizzato, quindi collegarli a risorse in altri progetti. I carichi di lavoro in esecuzione su queste risorse possono utilizzare i service account collegati per l'autenticazione, rendendo inutili i service account predefiniti.
Alcune funzionalità, come la federazione delle identità per i carichi di lavoro, richiedono la creazione di service account.
Se non utilizzi la federazione delle identità per i carichi di lavoro, valuta la possibilità di utilizzare i vincoli dei criteri dell'organizzazione per bloccare la federazione da tutti i provider di identità.
Tieni traccia dei service account
Nel tempo, man mano che crei sempre più service account, potresti perdere traccia di quale account di servizio viene utilizzato per quale scopo.
Il nome visualizzato di un account di servizio è un buon modo per acquisire ulteriori
informazioni sulaccount di serviziot, ad esempio lo scopo del service
account o una persona di contatto per l'account. Per i nuovi service account, puoi
compilare il nome visualizzato durante la creazione delaccount di serviziot. Per gli account di servizio
esistenti, utilizza il metodo serviceAccounts.update() per
modificare il nome visualizzato.
Utilizzare i service account con Compute Engine
Le istanze Compute Engine devono essere eseguite come service account per avere accesso ad altre risorse Google Cloud . Per proteggere le tue istanze Compute Engine, valuta quanto segue:
Puoi creare istanze nello stesso progetto con account di servizio diversi. Per modificare il account di servizio di un'istanza dopo la creazione, utilizza il metodo
instances.setServiceAccount.Per configurare l'autorizzazione per i service account collegati, devi configurare gli ambiti di accesso oltre a configurare i ruoli IAM.
Poiché le istanze dipendono dai service account per accedere alle risorseGoogle Cloud , evita di eliminare i service account quando sono ancora utilizzati dalle istanze in esecuzione.
Per scoprire di più sull'utilizzo dei service account con Compute Engine, consulta la sezione Service account nella documentazione di Compute Engine.
Identificare i service account inutilizzati
Dopo un po' di tempo, potresti avere service account nei tuoi progetti che non utilizzi più.
I service account inutilizzati creano un rischio per la sicurezza non necessario, pertanto ti consigliamo di disattivare i service account inutilizzati, quindi di eliminarli quando hai la certezza di non averne più bisogno. Puoi utilizzare i seguenti metodi per identificare gli account di servizio inutilizzati:
- Gli approfondimenti sugli service account indicano quali service account del tuo progetto non sono stati autenticati negli ultimi 90 giorni.
- Analizzatore attività ti consente di controllare quando è stato utilizzato l'ultima volta un service account o una chiave.
Puoi anche utilizzare le metriche di utilizzo del service account per monitorare l'utilizzo generale del service account e delle chiavi.
Se sei un cliente di Security Command Center Premium, puoi utilizzare Event Threat Detection per ricevere una notifica quando un account di servizio inattivo attiva un'azione. Gli account di servizio inattivi sono account di servizio inattivi da più di 180 giorni. Una volta utilizzato, un account di servizio non è più inattivo.
Elimina account di servizio
Prima di eliminare un account di servizio, disattivalo per assicurarti che non sia necessario. I service account disabilitati possono essere riattivati se sono ancora in uso.
Dopo aver confermato che un account di servizio non è necessario, puoi eliminarlo.
Ricreare i service account eliminati
È possibile eliminare un account di servizio e poi crearne uno nuovo con lo stesso nome.
Quando elimini un account di servizio, i relativi binding dei ruoli non vengono eliminati immediatamente. Al contrario, l'elenco delle associazioni di ruoli elenca il account di servizio con il prefisso
deleted:. Per un esempio, vedi
Criteri con entità eliminate.
Se crei un nuovo account di servizio con lo stesso nome di un account di servizio eliminato di recente, le vecchie associazioni potrebbero ancora esistere, ma non si applicheranno al nuovo service account 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 del account di servizio. Pertanto, le eventuali associazioni di ruoli esistenti per unaccount di serviziot eliminato non si applicano a un nuovoaccount di serviziont che utilizza lo stesso indirizzo email.
Analogamente, se colleghi un account di servizio a una risorsa, poi elimini il account di servizio e ne crei uno nuovo con lo stesso nome, il nuovo account di servizio non verrà collegato alla risorsa.
Per evitare questo comportamento imprevisto, valuta la possibilità di utilizzare un nome nuovo e univoco per ogni account di servizio. Inoltre, se elimini accidentalmente un account di servizio, puoi provare ad annullare l'eliminazione del service account anziché crearne uno nuovo.
Se non riesci a recuperare l'account di servizio originale e devi crearne uno nuovo con lo stesso nome e gli stessi ruoli, devi concedere i ruoli al nuovo service account. Per i dettagli, vedi Policy con entità eliminate.
Se vuoi che il nuovo account di servizio venga collegato alle stesse risorse delaccount di serviziot originale, esegui una delle seguenti operazioni:
- Per le istanze Compute Engine, puoi modificare il account di servizio collegato all'istanza per sostituire il account di servizio originale con il nuovo account di servizio.
- Per tutte le altre risorse, devi eliminare la risorsa esistente, quindi crearne una nuova dello stesso tipo e collegare il nuovo service account.
Passaggi successivi
- Scopri come creare service account.
- Scopri le best practice per lavorare con gli account di servizio.
- Consulta le best practice per la gestione delle chiavi degli account di servizio.
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