Best practice per l'utilizzo della federazione delle identità per i carichi di lavoro

La federazione delle identità per i carichi di lavoro consente alle applicazioni eseguite al di fuori di Google Cloud di assumere l'identità di un account di servizio utilizzando le credenziali di un provider di identità esterno.

L'utilizzo della federazione delle identità per i carichi di lavoro può aiutarti a migliorare la sicurezza consentendo alle applicazioni di utilizzare i meccanismi di autenticazione forniti dall'ambiente esterno e contribuendo a sostituire le chiavi degli account di servizio.

Per utilizzare la federazione delle identità per i carichi di lavoro in modo sicuro, devi configurarla in modo da proteggerti dalle seguenti minacce:

spoofing: un malintenzionato potrebbe tentare di falsificare l'identità di un altro utente per ottenere accesso non autorizzato alle risorse Google Cloud.
Escalation dei privilegi: un utente malintenzionato potrebbe sfruttare la federazione delle identità per i carichi di lavoro per ottenere l'accesso a risorse a cui altrimenti non avrebbe accesso.
Non rifiuto: un malintenzionato potrebbe nascondere la propria identità e le proprie azioni utilizzando credenziali esterne che rendono difficile il ricondizionamento delle azioni.

Questa guida illustra le best practice per decidere quando utilizzare la federazione delle identità per i carichi di lavoro e come configurarla in modo da ridurre al minimo i rischi.

Quando utilizzare la federazione delle identità per i carichi di lavoro

Best practice:

Utilizza la federazione delle identità per i carichi di lavoro per le applicazioni che hanno accesso a credenziali per l'ambiente.
Utilizza uno scambio di token aggiuntivo per usare credenziali dell'ambiente non supportate dalla federazione delle identità per i carichi di lavoro.
Utilizza la federazione delle identità per i carichi di lavoro per ridurre il numero di credenziali che richiedono la rotazione.

Utilizza la federazione delle identità per i carichi di lavoro per le applicazioni che hanno accesso a credenziali relative all'ambiente

Le applicazioni eseguite su cloud provider diversi da Google Cloud hanno spesso accesso a credenziali ambientali. Si tratta di credenziali che l'applicazione può ottenere senza dover eseguire alcuna autenticazione aggiuntiva. Ecco alcuni esempi:

Su AWS, le applicazioni di cui è stato eseguito il deployment su EC2 possono utilizzare i profili di istanza per assumere un ruolo e ottenere credenziali temporanee.
Su Azure, le applicazioni possono utilizzare identità gestite per ottenere i token di accesso.
Nelle azioni di GitHub, i flussi di lavoro possono ottenere token ID che riflettono l'identità del job di deployment.

Se le credenziali di ambiente sono token OpenID Connect (OIDC), asserzioni SAML o credenziali AWS, puoi configurare la federazione delle identità per i carichi di lavoro per consentire alle applicazioni di scambiare queste credenziali per token di accesso Google a breve durata. Se le credenziali dell'ambiente utilizzano un formato diverso, potresti essere in grado di scambiarle con un token OIDC o un'asserzione SAML e poi utilizzarle per la federazione delle identità per i carichi di lavoro.

Utilizza la federazione delle identità per i carichi di lavoro ogni volta che un'applicazione deve accedere a Google Cloud e ha accesso alle credenziali dell'ambiente.

Usa uno scambio di token aggiuntivo per usare credenziali dell'ambiente non supportate dalla federazione delle identità per i carichi di lavoro

In alcuni casi, un'applicazione potrebbe avere accesso alle credenziali dell'ambiente, ma i tipi di credenziali non sono supportati dalla federazione delle identità per i carichi di lavoro. In questi casi, controlla se uno scambio di token aggiuntivo consente di convertire le credenziali ambientali in un tipo di credenziale utilizzabile per la federazione delle identità per i carichi di lavoro.

Ad esempio, se l'applicazione viene eseguita in un ambiente Active Directory, potrebbe avere accesso alle credenziali Kerberos. Se nel tuo ambiente disponi di un provider di identità come Active Directory Federation Services (ADFS) che supporta l'autenticazione Windows integrata, puoi utilizzare queste credenziali Kerberos per l'autenticazione presso il provider di identità e ottenere un token di accesso OAuth che utilizzi il formato JWT. Utilizzando questa federazione delle identità per i token di accesso e dei carichi di lavoro, puoi consentire all'applicazione di eseguire un secondo scambio di token per ottenere credenziali Google di breve durata.

Il concatenamento degli scambi di token aumenta la complessità e potrebbe introdurre ulteriori dipendenze, senza dover gestire e proteggere le chiavi degli account di servizio.

Utilizza la federazione delle identità per i carichi di lavoro per ridurre il numero di credenziali che richiedono la rotazione

Le applicazioni che si integrano con un provider di identità OpenID o SAML spesso utilizzano un client secret (o una forma di secret diversa) per l'autenticazione presso il provider di identità. In genere, questo secret viene archiviato all'interno della configurazione dell'applicazione. Per consentire a un'applicazione di questo tipo di accedere a Google Cloud, devi decidere tra:

Creazione di una chiave dell'account di servizio e archiviazione insieme all'altro secret.
Utilizzare i token emessi dal provider di identità esistente e scambiarli con le credenziali Google utilizzando la federazione delle identità per i carichi di lavoro.

La prima opzione richiede due secret, mentre la seconda ne richiede solo uno. La riduzione del numero di secret può aiutarti a semplificare la rotazione dei secret, il che a sua volta può contribuire a migliorare la sicurezza.

Protezione dalle minacce di spoofing

Un pool di identità per i carichi di lavoro non contiene identità o account utente, il che lo rende diverso da una directory utente come Cloud Identity. Un pool di identità del carico di lavoro rappresenta invece una vista che mostra le identità provenienti da provider di identità esterni in modo che possano essere utilizzate come entità IAM.

A seconda di come configuri il pool di identità per i carichi di lavoro e i relativi provider, la stessa identità esterna potrebbe essere rappresentata come più entità IAM diverse oppure più identità esterne potrebbero essere mappate alla stessa entità IAM. Queste ambiguità potrebbero consentire ai malintenzionati di lanciare attacchi di spoofing.

La seguente sezione descrive le best practice per evitare mappature ambigue e ridurre il rischio di minacce di spoofing.

Best practice:

Utilizza le condizioni degli attributi durante la federazione con GitHub o altri provider di identità multi-tenant.
Utilizza un progetto dedicato per gestire provider e pool di identità per i carichi di lavoro.
Utilizza i vincoli dei criteri dell'organizzazione per disabilitare la creazione di provider di pool di identità per i carichi di lavoro in altri progetti.
Utilizza un singolo provider per pool di identità per i carichi di lavoro per evitare conflitti dei soggetti.
Evita di eseguire la federazione con lo stesso provider di identità due volte.
Proteggi l'endpoint dei metadati OIDC del tuo provider di identità.
Utilizza l'URL del provider del pool di identità per i carichi di lavoro come pubblico.
Utilizza attributi immutabili nelle mappature degli attributi.
Utilizza attributi non riutilizzabili nelle mappature degli attributi.
Non consentire la modifica delle mappature degli attributi.
Non fare affidamento su attributi non stabili o autorevoli.

Utilizza le condizioni degli attributi durante la federazione con GitHub o altri provider di identità multi-tenant

La federazione delle identità per i carichi di lavoro non gestisce una directory di account utente, ma implementa le identità basate sulle rivendicazioni. Di conseguenza, quando due token vengono emessi dallo stesso provider di identità (IdP) e le relative rivendicazioni sono mappate allo stesso valore google.subject, si presume che i due token identifichino lo stesso utente. Per scoprire quale IdP ha emesso un token, la federazione delle identità per i carichi di lavoro controlla e verifica l'URL dell'emittente del token.

Alcuni provider, come GitHub e Terraform Cloud, utilizzano un unico URL emittente per tutti i tenant. Per questi provider, l'URL dell'emittente identifica tutti i componenti GitHub o Terraform Cloud, non un'organizzazione GitHub o Terraform Cloud specifica.

Quando utilizzi questi provider di identità, non è sufficiente consentire alla federazione delle identità per i carichi di lavoro di controllare l'URL dell'emittente di un token per garantire che provenga da una fonte attendibile e che le relative rivendicazioni siano attendibili. Ti consigliamo di configurare una condizione dell'attributo della federazione delle identità per i carichi di lavoro per verificare che il token abbia avuto origine da un tenant attendibile o, nel caso di GitHub o Terraform Cloud, un'organizzazione attendibile.

Per scoprire di più, consulta la sezione Configurare una condizione dell'attributo.

Usa un progetto dedicato per gestire provider e pool di identità per i carichi di lavoro

Anziché gestire provider e pool di identità per i carichi di lavoro su più progetti, utilizza un unico progetto dedicato per gestire provider e pool di identità per i carichi di lavoro. L'utilizzo di un progetto dedicato ti aiuta a:

Assicurati che vengano utilizzati solo provider di identità attendibili per la federazione delle identità per i carichi di lavoro.
Controlla a livello centrale l'accesso alla configurazione di provider e pool di identità per i carichi di lavoro.
Applica mappature e condizioni degli attributi coerenti in tutti i progetti e le applicazioni.

Puoi utilizzare i vincoli dei criteri dell'organizzazione per applicare la disciplina di utilizzo di un progetto dedicato per gestire provider e pool di identità per i carichi di lavoro.

Utilizza i vincoli dei criteri dell'organizzazione per disabilitare la creazione di provider di pool di identità per i carichi di lavoro in altri progetti

Gli utenti con l'autorizzazione per creare provider di pool di identità per i carichi di lavoro possono creare provider e pool di identità per i carichi di lavoro che potrebbero essere ridondanti per quelli che gestisci in un progetto dedicato.

Puoi impedire la creazione di nuovi provider di pool di identità per i carichi di lavoro utilizzando il vincolo del criterio dell'organizzazione constraints/iam.workloadIdentityPoolProviders con una regola impostata su Nega tutti.

Applica questi vincoli alla radice della gerarchia dell'organizzazione per negare la creazione di nuovi provider di pool di identità per i carichi di lavoro per impostazione predefinita. Crea eccezioni per i progetti in cui vuoi consentire la gestione di provider e pool di identità per i carichi di lavoro applicando un vincolo di criterio che consenta l'accesso a determinati account AWS o provider OIDC attendibili.

Utilizza un singolo provider per pool di identità per i carichi di lavoro per evitare conflitti tra i soggetti

La federazione delle identità per i carichi di lavoro consente di creare più di un provider per pool di identità dei carichi di lavoro. Utilizzare più provider può essere utile se le identità sono gestite da più provider, ma vuoi nascondere questa complessità ai carichi di lavoro in esecuzione su Google Cloud.

L'utilizzo di più provider comporta il rischio di conflitti dei soggetti, in cui la mappatura degli attributi per google.subject di un provider restituisce lo stesso valore della mappatura degli attributi per un altro provider. Il risultato di questa collisione è che più identità esterne sono mappate alla stessa entità IAM, rendendo le identità esterne indistinguibili in Cloud Audit Logs.

Per evitare conflitti tra i soggetti, utilizza un singolo provider per pool di identità per i carichi di lavoro. Se hai bisogno di eseguire la federazione con più provider, crea più pool di identità per i carichi di lavoro, ciascuno utilizzando un singolo provider di identità per i carichi di lavoro.

Evita di eseguire la federazione con lo stesso provider di identità due volte

Puoi eseguire la federazione con lo stesso provider di identità più volte creando più provider di pool di identità per carichi di lavoro che utilizzano la stessa configurazione o una configurazione simile. Se questi provider appartengono allo stesso pool di identità per i carichi di lavoro, una configurazione di questo tipo può causare collisioni dei soggetti. Se i provider appartengono a pool di identità per i carichi di lavoro diversi, non possono verificarsi conflitti tra i soggetti e la stessa identità esterna viene invece rappresentata come entità IAM diverse.

La mappatura di una singola identità esterna a più entità IAM rende più difficile analizzare le risorse a cui ha accesso una determinata identità esterna. Una tale ambiguità può anche aumentare il rischio quando tenta di revocare l'accesso: un amministratore potrebbe revocare l'accesso per un'entità, ma potrebbe non essere consapevole dell'esistenza di un'altra entità, causando inavvertitamente l'accesso all'identità esterna.

Per ridurre al minimo il rischio di ambiguità, evita di eseguire la federazione con lo stesso provider di identità più di una volta. Crea invece un unico pool di identità per i carichi di lavoro e un singolo provider e utilizza una mappatura e una condizione degli attributi che garantiscano l'utilizzo per tutte le identità esterne che richiedono l'accesso alle risorse Google Cloud.

Proteggi l'endpoint dei metadati OIDC del tuo provider di identità

Quando esegui la federazione con un provider OpenID Connect, la federazione delle identità per i carichi di lavoro scarica periodicamente i metadati OIDC dal tuo provider di identità. La federazione delle identità per i carichi di lavoro utilizza i metadati dell'IdP e il set di chiavi web JSON (JWKS) per convalidare i token.

Per garantire l'autenticità, la comunicazione con il tuo provider di identità è protetta tramite TLS. Se il deployment del provider viene eseguito dietro un bilanciatore del carico o un proxy inverso che termina TLS, la connessione TLS garantisce l'autenticità del bilanciatore del carico o del proxy inverso, ma non del provider di identità effettivo.

Un malintenzionato potrebbe sfruttare questa configurazione lanciando un attacco man in the middle (MITM) in cui riconfigura il bilanciatore del carico per consentire il passaggio delle richieste JWKS a un endpoint dannoso che gestisce un set di chiavi diverso. Lo scambio di JWKS consente a un utente malintenzionato di firmare token che sono considerati validi dalla federazione delle identità dei carichi di lavoro e potrebbe consentire lo spoofing delle identità di altri utenti.

Per proteggerti dagli scambi JWKS, assicurati che il deployment dell'IdP sia protetto in modo da proteggerlo dagli attacchi MITM.

Utilizza l'URL del provider del pool di identità per i carichi di lavoro come pubblico

Quando esegui la federazione con un provider OpenID Connect, la federazione delle identità per i carichi di lavoro verifica che il pubblico dei token (codificato nell'attestazione aud) corrisponda all'impostazione del pubblico consentita del provider. Allo stesso modo, quando esegui la federazione con un provider SAML, la federazione delle identità per i carichi di lavoro verifica che l'asserzione SAML specifichi una restrizione del pubblico corrispondente al pubblico previsto.

Per impostazione predefinita, la federazione delle identità per i carichi di lavoro prevede che il pubblico corrisponda all'URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID che identifica in modo univoco il provider del pool di identità per i carichi di lavoro. La richiesta di token e asserzioni per l'utilizzo di questo URL come pubblico contribuisce a ridurre il rischio di un attacco da parte di un vicepresidente confuso. In un attacco di questo tipo, un malintenzionato presenta un token o un'asserzione SAML alla federazione delle identità per i carichi di lavoro che non era destinata a essere utilizzata per la federazione delle identità per i carichi di lavoro, ma per altre API.

Richiedere che il token o l'asserzione contenga l'URL del provider del pool di identità dei carichi di lavoro di destinazione per garantire che i client possano utilizzare solo token e attestazioni emessi appositamente per la federazione delle identità per i carichi di lavoro.

Utilizza attributi immutabili nelle mappature degli attributi

Per concedere a un'autorizzazione di identità esterna l'identità di un account di servizio, devi creare un'associazione IAM che fa riferimento all'identità esterna in base a oggetto, gruppo o attributo personalizzato. L'oggetto, il gruppo e gli attributi personalizzati dell'identità esterna derivano dagli attributi che il provider di identità esterno passa alla federazione delle identità per i carichi di lavoro durante lo scambio dei token.

Alcuni provider di identità consentono agli utenti di modificare alcuni dei propri attributi. Ad esempio, un utente potrebbe essere autorizzato a modificare il proprio indirizzo email o gli alias. Se le associazioni IAM fanno riferimento ad attributi modificabili, gli utenti potrebbero perdere accidentalmente l'accesso a determinate risorse modificando il proprio profilo utente. O peggio ancora, i malintenzionati potrebbero essere in grado di ottenere l'accesso non autorizzato ad altre risorse modificando deliberatamente gli attributi utente in modo che corrispondano alle associazioni IAM esistenti.

Per proteggerti da questa minaccia di spoofing, limita le mappature degli attributi ad attributi che non possono essere modificati dall'utente o che non possono essere modificati.

Utilizzare attributi non riutilizzabili nelle mappature degli attributi

Quando concedi un'autorizzazione di identità esterna per impersonare un account di servizio e in seguito elimini l'utente nel provider di identità esterno, l'associazione IAM dell'account di servizio rimane attiva.

Se in un secondo momento aggiungi un nuovo utente al provider di identità esterno e l'utente condivide determinati attributi con l'utente eliminato in precedenza (ad esempio, lo stesso indirizzo email), gli utenti vecchi e nuovi non saranno distinguibili per la federazione delle identità per i carichi di lavoro. Di conseguenza, un'associazione IAM destinata solo a fare riferimento al vecchio utente potrebbe essere applicata anche al nuovo utente.

Per evitare queste ambiguità, utilizza mappature degli attributi basate esclusivamente su attributi che non possono essere riutilizzati nel tempo, ad esempio un ID utente univoco.

Se i criteri della tua azienda consentono il riutilizzo di attributi come gli indirizzi email, evita di utilizzare questi attributi nelle mappature degli attributi e utilizza un attributo diverso che sia garantito che sia univoco nel tempo.

Non consentire la modifica delle mappature degli attributi

La federazione delle identità per i carichi di lavoro utilizza le mappature degli attributi per selezionare gli attributi forniti dal provider di identità esterno da incorporare in un token STS e la modalità di traduzione dei nomi degli attributi. La configurazione delle mappature degli attributi è un passaggio fondamentale per impostare la relazione di attendibilità tra il provider di identità esterno e Google Cloud.

Le mappature degli attributi sono fondamentali anche per la sicurezza dell'utilizzo della federazione delle identità per i carichi di lavoro: se hai concesso a un'entità o un set di entità federate la possibilità di impersonare un account di servizio e poi cambiare la mappatura degli attributi, potresti cambiare gli utenti che hanno accesso all'account di servizio.

Per modificare i mapping degli attributi è necessaria l'autorizzazione iam.googleapis.com/workloadIdentityPoolProviders.update. I ruoli con questa autorizzazione includono:

Proprietario (roles/owner)
Amministratore pool Workload Identity IAM (roles/iam.workloadIdentityPoolAdmin)

Se un malintenzionato ha l'autorizzazione per modificare le mappature degli attributi, potrebbe essere in grado di cambiare le regole di mappatura in modo da consentire lo spoofing della propria identità e ottenere l'accesso a un account di servizio. Per evitare questo tipo di modifiche dannose, assicurati che solo alcuni utenti amministrativi abbiano l'autorizzazione per modificare i mapping degli attributi.

Valuta la possibilità di creare un progetto Google Cloud dedicato per la gestione dei pool di identità dei carichi di lavoro, in modo da limitare il rischio che agli utenti venga inavvertitamente concesso uno di questi ruoli a un livello superiore nella gerarchia delle risorse.

Non fare affidamento su attributi non stabili o autorevoli

Un provider di identità utilizza gli attributi per comunicare informazioni sugli utenti autenticati. I provider di identità garantiscono in genere che alcuni attributi sono autorevoli, mentre altri non lo sono. Ad esempio, un provider di identità esterno potrebbe incorporare sia un nome utente sia un ID utente in un token OIDC. Entrambi gli attributi identificano in modo univoco un utente e potrebbero sembrare intercambiabili. Tuttavia, il provider di identità esterno potrebbe garantire che l'ID utente sia stabile e autorevole, ma consentire la modifica dei nomi utente.

Se le mappature degli attributi si basano su attributi non stabili o autorevoli, un malintenzionato potrebbe riuscire a eseguire lo spoofing della propria identità modificando il proprio profilo utente nel provider di identità esterno. Ad esempio, potrebbero cambiare il nome utente con quello di un utente che è stato eliminato di recente nel provider di identità esterno, ma che ha ancora accesso a un account di servizio su Google Cloud.

Per prevenire questi attacchi di spoofing, assicurati che i mapping degli attributi si basino solo su attributi che il provider di identità esterno garantisce essere stabili e autorevoli.

Protezione dalle minacce di non ripudio

Ogni volta che noti attività sospette che interessano una delle tue risorse su Google Cloud, Cloud Audit Logs sono un'importante fonte di informazioni per scoprire quando si è verificata l'attività e quali utenti sono stati coinvolti.

Quando un'applicazione utilizza la federazione delle identità per i carichi di lavoro, impersona un account di servizio. In Cloud Audit Logs, qualsiasi attività eseguita dall'applicazione viene attribuita all'account di servizio impersonato. Per ricostruire l'intera catena di eventi che hanno portato all'attività, devi essere in grado di correlare Cloud Audit Logs con i log del tuo provider di identità in modo da poter scoprire quale identità esterna è stata coinvolta e perché è stata eseguita un'attività.

Questa sezione descrive le best practice che possono aiutarti a mantenere un audit trail non ripudiabile.

Best practice:

Abilita i log degli accessi ai dati per le API IAM.
Utilizza una mappatura dei soggetti univoca.

Abilita i log degli accessi ai dati per le API IAM

Per aiutarti a identificare e comprendere gli scenari di rappresentazione degli account di servizio, servizi come Compute Engine includono una sezione serviceAccountDelegationInfo in Cloud Audit Logs. Quando un'applicazione utilizza la federazione delle identità per i carichi di lavoro, questa sezione include l'oggetto dell'entità utilizzata per impersonare l'account di servizio.

Non tutti i servizi includono dettagli relativi alla rappresentazione in Cloud Audit Logs. Per mantenere un audit trail non ripetibile, è necessario anche registrare tutti gli eventi di rappresentazione abilitando i log degli accessi ai dati per l'API Security Token Service e l'API Identity and Access Management. Abilita questi log per tutti i progetti Cloud che contengono pool di identità per i carichi di lavoro o account di servizio utilizzati per la federazione delle identità per i carichi di lavoro.

Se abiliti questi log, ti assicuri che venga aggiunta una voce a Cloud Audit Logs ogni volta che un'applicazione utilizza la federazione delle identità per i carichi di lavoro per scambiare una credenziale esterna e impersona un account di servizio.

Utilizza una mappatura del soggetto univoca

Il oggetto dell'entità utilizzato nella sezione serviceAccountDelegationInfo nelle voci di Cloud Audit Logs è determinato dalla mappatura degli attributi del provider del pool di identità per i carichi di lavoro per google.subject.

Quando individui attività sospette e devi scoprire quale identità esterna è stata coinvolta, devi poter cercare un'identità esterna in base al valore google.subject corrispondente.

Allo stesso modo, quando un'identità esterna è stata compromessa e devi scoprire se l'identità è stata utilizzata per accedere alle risorse Google Cloud, devi essere in grado di trovare le voci di Cloud Audit Logs corrispondenti all'identità esterna.

Quando definisci la mappatura degli attributi per un provider di pool di identità per i carichi di lavoro, scegli una mappatura univoca per google.subject in modo che:

Un'identità esterna viene mappata a un solo valore google.subject.
Un valore google.subject viene mappato a una sola identità esterna.
Puoi cercare un'identità esterna in base al suo valore google.subject.

L'utilizzo di una mappatura degli attributi che soddisfi questi criteri di univocità ti consente di cercare le identità esterne in base al loro valore google.subject e viceversa.

Protezione dalle minacce di escalation dei privilegi

Per applicare il principio del privilegio minimo quando utilizzi la federazione delle identità per i carichi di lavoro, devi:

limitare il numero di identità esterne che possono impersonare un account di servizio
limitare le risorse a cui può accedere un account di servizio

Una configurazione eccessivamente permissiva può portare a una situazione in cui un utente malintenzionato può utilizzare un'identità esterna per aumentare i propri privilegi e accedere a risorse a cui non dovrebbe avere accesso.

Le sezioni seguenti forniscono best practice che possono aiutarti a proteggerti dalle minacce di escalation dei privilegi.

Best practice:

Utilizza gli account di servizio che risiedono nello stesso progetto delle risorse a cui devi accedere.
Utilizzare un account di servizio dedicato per ogni applicazione.
Evita di concedere l'accesso a tutti i membri di un pool.

Usa gli account di servizio che risiedono nello stesso progetto delle risorse a cui devi accedere

Quando un client utilizza la federazione delle identità per i carichi di lavoro utilizzando le librerie client o l'API REST, segue un processo in tre passaggi:

Ottieni una credenziale dal provider di identità attendibile.
Scambia la credenziale per un token del servizio token di sicurezza.
Utilizza il token di Security Token Service per impersonare un account di servizio e ottenere un token di accesso Google di breve durata.

Per l'ultimo passaggio, utilizza un account di servizio che risiede nello stesso progetto delle risorse a cui devi accedere. L'utilizzo di un account di servizio gestito nello stesso progetto consente di applicare autorizzazioni di accesso più restrittive e di decidere più facilmente quando l'account di servizio potrebbe non essere più necessario.

Usa un account di servizio dedicato per ogni applicazione

Se hai più applicazioni che utilizzano la federazione delle identità per i carichi di lavoro per accedere alle risorse nello stesso progetto, crea un account di servizio dedicato per ogni applicazione. L'utilizzo di account di servizio specifici dell'applicazione ti aiuta a evitare di concedere autorizzazioni eccessive concedendo solo l'accesso alle risorse richieste da ogni singola applicazione.

Evita di concedere l'accesso a tutti i membri di un pool

Prima che un'identità esterna possa impersonare un account di servizio, devi concedere il ruolo roles/iam.workloadIdentityUser nell'account di servizio. Se concedi questo ruolo, evita di concederlo a tutti i membri del pool Workload Identity. Concedi invece il ruolo a identità esterne o identità che corrispondono a determinati criteri.

Inizialmente, il numero di utenti esterni che hanno bisogno di accedere alle risorse Google Cloud potrebbe essere ridotto. La condizione degli attributi del pool di identità per i carichi di lavoro e la configurazione del provider di identità potrebbero pertanto consentire solo a poche identità esterne di utilizzare la federazione delle identità per i carichi di lavoro.

Quando in seguito inserisci nuovi carichi di lavoro in Google Cloud, potresti dover modificare la configurazione del provider di identità o la condizione degli attributi del pool di identità per i carichi di lavoro in modo che consenta identità esterne aggiuntive.

Concedendo il ruolo roles/iam.workloadIdentityUser solo a identità esterne specifiche, puoi assicurarti di aumentare in sicurezza un pool di identità per i carichi di lavoro senza concedere inavvertitamente un numero maggiore di accessi per la rappresentazione di identità esterne del necessario.

Passaggi successivi

Scopri le best practice per lavorare con gli account di servizio.
Scopri di più sulle best practice per la gestione delle chiavi degli account di servizio.