Le entità possono utilizzare i service account per l'autenticazione in diversi modi. Ogni tipo di autenticazione richiede che l'entità disponga di autorizzazioni IAM (Identity and Access Management) specifiche per il account di servizio.
Questa pagina descrive i ruoli che puoi concedere alle entità per consentire loro di impersonare service account o collegare service account alle risorse. Descrive inoltre le autorizzazioni necessarie negli scenari comuni.
Per scoprire diversi modi per autenticarsi con un account di servizio, vedi Credenziali del service account e Rappresentazione del service account.
Ruoli del service account
Questa sezione descrive i ruoli che consentono alle entità di autenticarsi con i service account. Per scoprire come concedere e revocare questi ruoli, consulta Gestire l'accesso ai service account.
Ruolo Service Account User
Il ruolo Utente account di servizio (roles/iam.serviceAccountUser) consente a un'entità di
collegare un service account a una risorsa. Quando il codice
in esecuzione su quella risorsa deve autenticarsi, può ottenere le credenziali per il
account di servizio collegato.
Questo ruolo non consente alle entità di
creare credenziali di breve durata per i service account o di
utilizzare il flag --impersonate-service-account per
Google Cloud CLI. Per completare queste attività, devi disporre del
ruolo Creatore token service account per il service
account.
Ruolo Creatore token service account
Il ruolo Creatore token service account (roles/iam.serviceAccountTokenCreator)
consente alle entità di creare credenziali di breve durata per un
account di servizio.
Il ruolo Creatore token service account consente di creare i seguenti tipi di credenziali di breve durata:
- Token di accesso OAuth 2.0, che puoi utilizzare per l'autenticazione con le API di Google
- Token ID OpenID Connect (OIDC)
- Token web JSON (JWT) firmati e blob binari
Il ruolo Creatore token account di servizio consente inoltre alle entità di utilizzare il
flag --impersonate-service-account per
gcloud CLI. Quando utilizzi questo flag, gcloud CLI
crea automaticamente credenziali di breve durata per ilaccount di serviziot.
Le autorizzazioni del ruolo includono quanto segue:
iam.serviceAccounts.getAccessToken: consente di creare token di accesso OAuth 2.0iam.serviceAccounts.getOpenIdToken: consente di creare token ID OpenID Connect (OIDC)iam.serviceAccounts.implicitDelegation: consente agli account di servizio di ottenere token in una catena di delegaiam.serviceAccounts.signBlob: consente di firmare i blob binariiam.serviceAccounts.signJwt: consente di firmare i JWT
Service Account OpenID Connect Identity Token Creator
Il ruolo Service Account OpenID Connect Identity Token Creator
(roles/iam.serviceAccountOpenIdTokenCreator) consente alle entità
di creare token ID OIDC di breve durata. Utilizza questo ruolo se devi solo creare token ID OIDC. Se devi creare altri tipi di
token, utilizza il ruolo Creatore token account di servizio
invece.
Il ruolo include l'autorizzazione iam.serviceAccounts.getOpenIdToken, che
consente di creare un token ID OIDC.
Ruolo Workload Identity User
Il ruolo Utente Workload Identity (roles/iam.workloadIdentityUser) consente
alle entità di rappresentare i service account dei workload GKE.
Le autorizzazioni del ruolo includono quanto segue:
iam.serviceAccounts.getAccessToken: consente di creare token di accesso OAuth 2.0iam.serviceAccounts.getOpenIdToken: consente di creare token ID OpenID Connect (OIDC)
Autorizzazioni service account per scenari comuni
Gli account di servizio possono essere utilizzati in molti scenari diversi e ognuno di questi richiede determinate autorizzazioni. Questa sezione descrive gli scenari comuni e le autorizzazioni richieste.
Collegamento di service account alle risorse
Se vuoi avviare un job a lunga esecuzione che esegue l'autenticazione come account di servizio, devi collegare unaccount di serviziot alla risorsa che eseguirà il job.
Autorizzazioni:
- Autorizzazioni per creare la risorsa
iam.serviceAccounts.actAs
Per trovare i ruoli che includono queste autorizzazioni, cerca le autorizzazioni nell'elenco dei ruoli.
Esistono diverse risorse Google Cloud che possono eseguire job a lunga esecuzione come account di servizio. Alcuni esempi di queste risorse includono:
- VM Compute Engine
- App App Engine
- Cloud Run Functions
Quando crei queste risorse, hai la possibilità di allegare un service account. Questo account di servizio funge da identità della risorsa.
Per creare una risorsa e collegare un account di servizio, devi disporre delle autorizzazioni per creare la risorsa e per collegare il account di servizio alle risorse.
L'autorizzazione per collegare i service account alle risorse viene fornita da qualsiasi ruolo
che include l'autorizzazione iam.serviceAccounts.actAs, ad esempio il
ruolo Utente service account (roles/iam.serviceAccountUser).
Dopo aver creato la risorsa e averle collegato un account di servizio, puoi avviare un job a lunga esecuzione sulla risorsa. Il job viene eseguito come account di servizio collegato alla risorsa e utilizza questo account di servizio per autorizzare le richieste alle APIGoogle Cloud .
Per scoprire di più sull'associazione di service account alle risorse, consulta Associazione di un account di servizio a una risorsa.
Rappresentare un account di servizio
Autorizzazioni:
iam.serviceAccounts.getAccessTokeniam.serviceAccounts.signBlobiam.serviceAccounts.signJwtiam.serviceAccounts.implicitDelegation
Ruoli:
roles/iam.serviceAccountTokenCreator(Creatore token service account)
Una volta concesse le autorizzazioni richieste, un utente (o un altro account di servizio) può simulare l'identità delaccount di serviziot in alcuni scenari comuni.
Innanzitutto, l'utente può autenticarsi come account di servizio. Ad esempio, possono
ottenere credenziali di breve durata per il account di servizio utilizzando l'autorizzazione
iam.serviceAccounts.getAccessToken e chiamando il metodo
generateAccessToken(). In alternativa, possono utilizzare il
flag --impersonate-service-account per
gcloud CLI per rappresentare l'account di servizio. Quando un utente
esegue l'autenticazione come account di servizio, può inviare comandi a
Google Cloud e accedere a tutte le risorse a cui l'account di servizio ha
accesso.
In secondo luogo, l'utente può ottenere 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 viene sempre conservata in escrow e non è mai direttamente
esposta. signBlob() consente la firma di payload arbitrari (come
URL firmati di Cloud Storage), mentre signJwt() consente solo la firma
di JWT ben formati.
Infine, l'utente può rappresentare il account di servizio senza mai recuperare una
credenziale per ilaccount di serviziot. Si tratta di un caso d'uso avanzato ed è supportato solo per l'accesso programmatico tramite il metodo generateAccessToken(). In scenari con almeno tre service account, ovvero A, B e C: account di servizio A può ottenere un token di accesso per account di servizio C se 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.serviceAccountOpenIdTokenCreator(Service Account OpenID Connect Identity Token Creator)
Un utente (o un servizio) può generare un token JWT compatibile con OpenID Connect (OIDC)
firmato dal provider Google OIDC (accounts.google.com) che rappresenta
l'identità deaccount di serviziont utilizzando l'autorizzazione iam.serviceAccounts.getOpenIdToken.
Questi token non sono accettati direttamente dalla maggior parte delle API di Google senza che la tua organizzazione implementi un'ulteriore federazione delle identità per concedere l'accesso a Google.
Generazione di chiavi private esterne
Autorizzazioni:
iam.serviceAccountKeys.create
Ruoli:
roles/editor(editor)roles/iam.serviceAccountKeyAdmin(Service Account Key Admin)
Un utente o un servizio può generare materiale della chiave privata esterna (RSA) che può essere
utilizzato per l'autenticazione diretta a Google come account di servizio. Questo materiale
della chiave può essere utilizzato con le librerieCredenziali predefinite dell'applicazionee (ADC)
o con il comando gcloud auth
activate-service-account. Chiunque ottenga l'accesso al materiale della chiave avrà pieno
accesso a tutte le risorse a cui ha accesso ilaccount di serviziot. Questo materiale
della chiave privata deve essere trattato con la massima attenzione e deve essere
considerato meno sicuro quanto più a lungo esiste. Pertanto, la rotazione
del materiale delle chiavi private è fondamentale per mantenere una sicurezza elevata.
Autorizzazioni del service account che attivano altre funzionalità
Alcune autorizzazioni per le credenziali del account di servizio consentono più funzionalità.
Ad esempio, iam.serviceAccounts.signBlob e
iam.serviceAccounts.signJwt consentono anche alle entità di generare token di accesso e
token ID per un account di servizio. Inoltre, poiché
iam.serviceAccounts.signBlob consente alle entità di firmare qualsiasi tipo di dati, consente
anche di firmare i JWT.
Prima di aggiungere una di queste autorizzazioni ai ruoli personalizzati, assicurati di comprendere quali azioni consente ogni autorizzazione.
La tabella seguente mostra le operazioni abilitate da queste autorizzazioni:
| Autorizzazione | Operazioni abilitate |
|---|---|
iam.serviceAccounts.getAccessToken |
Recupera un token di accesso per il account di servizio |
iam.serviceAccounts.getOpenIdToken |
Ottieni un token ID per il account di servizio |
iam.serviceAccounts.signJwt |
|
iam.serviceAccounts.signBlob |
|
Best practice per la concessione dei ruoli sugli account di servizio
Negli scenari in cui a un account di servizio sono state concesse autorizzazioni per eseguire operazioni con privilegi elevati, fai attenzione quando concedi il ruolo Utente service account o le autorizzazioni incluse a un utente su quel account di servizio.
I service account rappresentano la sicurezza a livello di servizio. La sicurezza del servizio è determinata dalle persone che dispongono di ruoli IAM per gestire e utilizzare i service account e dalle persone che detengono chiavi del service account per questi service account. Le best practice per garantire la sicurezza includono quanto segue:
- Utilizza l'API IAM per controllare gli account di servizio, le chiavi e le policy di autorizzazione per questi service account.
- Se i tuoi service account non hanno bisogno di chiavi, disattivali o eliminali.
- Se gli utenti non hanno bisogno dell'autorizzazione per gestire o utilizzare i service account, rimuovili dal criterio di autorizzazione applicabile.
- Scopri come la concessione di determinate autorizzazioni per i service account può attivare effettivamente altre funzionalità.
- Assicurati che i service account dispongano del minor numero possibile di autorizzazioni. Utilizza
service account predefiniti con cautela, perché
viene automaticamente concesso il ruolo Editor (
roles/editor) sul progetto.
Per saperne di più sulle best practice, consulta Best practice per l'utilizzo dei service account.
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