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

La federazione delle identità per i carichi di lavoro consente l'esecuzione delle applicazioni al di fuori di Google Cloud impersonare 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 può aiutarti 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 ti protegge dalle seguenti minacce:

• Spoofing: un utente malintenzionato potrebbe tentare di falsificare l'identità di un altro utente per accedere alle risorse Google Cloud senza autorizzazione.
• Escalation dei privilegi: un utente malintenzionato potrebbe sfruttare la federazione delle identità per la forza lavoro per ottenere l'accesso a risorse a cui altrimenti non avrebbe accesso.
• Non rifiuto: un utente malintenzionato potrebbe nascondere la propria identità e le proprie azioni usando credenziali esterne che rendono difficile il rintracciamento delle azioni. a loro.

Questa guida presenta le best practice per decidere quando utilizzare Federazione delle identità per i carichi di lavoro e come configurarla per agevolare la minimizzare 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 alle credenziali ambientali.
Utilizza uno scambio di token aggiuntivo per utilizzare le credenziali ambient che non sono supportate dalla federazione di Workload Identity.
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 alle credenziali ambientali

Le applicazioni in esecuzione su cloud provider diversi da Google Cloud spesso hanno accesso alle credenziali ambient. Si tratta delle credenziali utilizzate dall'applicazione che è possibile ottenere senza dover eseguire alcuna autenticazione aggiuntiva. Ecco alcuni esempi:

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

Se le credenziali di contesto sono token OpenID Connect (OIDC), assert SAML o credenziali AWS, puoi configurare la federazione delle identità per i carichi di lavoro per consentire alle applicazioni di scambiare queste credenziali con token di accesso Google di breve durata. Se le credenziali ambient utilizzano un formato diverso, potresti essere in grado di scambiarle per un token OIDC o un'affermazione SAML innanzitutto, per poi utilizzarle per la federazione delle identità del carico di lavoro.

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

Utilizza uno scambio di token aggiuntivo per usare credenziali ambientali 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 da Workload Identity Federation. In queste casi, verifica se uno scambio di token aggiuntivo ti consente di convertire l'ambiente credenziale in un tipo di credenziale che puoi utilizzare 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 è presente un provider di identità come Active Directory Federation Services (AD FS) che supporta l'autenticazione Windows integrata, puoi utilizzare queste credenziali Kerberos per autenticarti al provider di identità e ottenere un token di accesso OAuth che utilizza il formato JWT. Utilizzo di questo accesso e la federazione delle identità per i carichi di lavoro, potrai quindi lasciare che l'applicazione esegua un secondo scambio di token per ottenere credenziali Google di breve durata.

L'accodamento degli scambi di token aumenta la complessità e potrebbe introdurre dipendenze aggiuntive, ma ti consente di non 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 segreto client (o una forma diversa di segreto) per autenticarsi al provider di identità. In genere, questo segreto viene memorizzato nella configurazione dell'applicazione. Per consentire all'applicazione di accedere a Google Cloud, devi decidere tra:

1. Creare una chiave dell'account di servizio e memorizzarla insieme all'altra secret.
2. Utilizzare i token emessi dal provider di identità esistente e scambiarli per 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, a loro volta può contribuire a migliorare la sicurezza.

Protezione dalle minacce di spoofing

Un pool di identità del carico di lavoro non contiene identità o account utente, il che lo distingue da una directory utente come Cloud Identity. Un pool Workload Identity rappresenta invece una visualizzazione che mostra le identità dei provider di identità esterni in modo che possano essere utilizzate come entità IAM.

A seconda di come configuri il pool di identità di lavoro e i relativi provider, la stessa identità esterna potrebbe essere rappresentata come più entità IAM diverse o diverse identità esterne potrebbero essere mappate allo stesso entità IAM. Tale le ambiguità potrebbero consentire a malintenzionati di lanciare attacchi di spoofing.

La sezione seguente descrive le best practice che ti aiutano a evitare mappature ambigue e a 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 i provider e i pool di identità per i carichi di lavoro.
Utilizza i vincoli dei criteri dell'organizzazione per disattivare la creazione di provider di pool di identità di carico di lavoro in altri progetti.
Utilizza un solo provider per pool di identità per i carichi di lavoro per evitare collisioni di soggetti.
Evita di eseguire la federazione due volte con lo stesso provider di identità.
Proteggi l'endpoint dei metadati OIDC del tuo provider di identità.
Utilizza l'URL del provider del pool di identità 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. implementa invece identità basate sulle rivendicazioni: Di conseguenza, quando due token vengono emessi dallo stesso provider di identità (IdP) e le relative attestazioni mappano allo stesso google.subject, si presume che i due token identifichino lo stesso utente. Per scoprire quale IdP ha emesso un token, Workload Identity Federation ispeziona e verifica l'URL dell'emittente del token.

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

Questi provider di identità non sono sufficienti per consentire La federazione delle identità per i carichi di lavoro controlla l'URL emittente di un token per verificare che proviene da una fonte attendibile e che le sue dichiarazioni siano attendibili. I nostri suggerimenti devi configurare una condizione degli attributi della federazione delle identità per i carichi di lavoro per verificare che il token abbia avuto origine da un tenant attendibile oppure, nel caso di GitHub Terraform Cloud, un'organizzazione affidabile.

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

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

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

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

Puoi usare i vincoli dei criteri dell'organizzazione per applicare la disciplina di utilizzo un progetto dedicato per gestire i provider e i 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 a creare provider di pool di identità per i carichi di lavoro possono creare i pool di identità per i carichi di lavoro e i provider che potrebbero essere ridondanti da gestire in un progetto dedicato.

Puoi impedire la creazione di nuovi provider di pool di identità dei carichi di lavoro utilizzando il constraints/iam.workloadIdentityPoolProviders vincolo dei criteri dell'organizzazione con una regola impostata su Rifiuta tutto.

Applica questi vincoli alla radice della gerarchia dell'organizzazione per negare la creazione di nuovi provider di pool di identità dei carichi di lavoro per impostazione predefinita. Creare eccezioni per i progetti in cui vuoi consentire la gestione dei pool di identità per i carichi di lavoro mediante l'applicazione di un vincolo di criterio che consenta ad AWS o i provider OIDC.

Utilizza un solo provider per pool di identità per i carichi di lavoro per evitare collisioni di soggetti

La federazione delle identità per i carichi di lavoro consente di creare più di un provider per ogni carico di lavoro pool di identità. L'utilizzo di 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 introduce il rischio di collisioni degli oggetti, in cui la mappatura degli attributi per google.subject di un provider restituisce lo stesso valore della mappatura degli attributi di un altro provider. Il risultato di una collisione di questo tipo è che più identità esterne vengono mappate allo stesso principale IAM, rendendole indistinguibili nei log di controllo di Cloud.

Per evitare collisioni di 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ù identità per i carichi di lavoro ognuno dei quali usa 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 più volte con lo stesso provider di identità creando più Provider di pool di identità per i carichi di lavoro che utilizzano la stessa configurazione o una configurazione simile. Se questi provider appartengono allo stesso pool di identità del carico di lavoro, questa configurazione può portare a collisioni degli oggetti. Se i provider appartengono a pool di identità di carichi di lavoro diversi, non possono verificarsi collisioni degli oggetti soggetti e la stessa identità esterna viene rappresentata come diversi principali IAM.

La mappatura di una singola identità esterna a più entità IAM consente di ottenere di più difficile analizzare a quali risorse ha accesso una determinata identità esterna. Tale ambiguità può anche aumentare il rischio quando si cerca di revocare l'accesso: l'amministratore potrebbe revocare l'accesso per un'entità, ma potrebbe non essere a conoscenza del l'esistenza di un'altra entità, causando inavvertitamente l'identità esterna manterranno l'accesso.

Per ridurre al minimo il rischio di ambiguità, evita di eseguire la federazione con lo stesso fornitore di servizi di identità più di una volta. Crea invece un singolo pool di identità per i carichi di lavoro provider e utilizzare una mappatura e una condizione degli attributi che ne garantiscano la possibilità utilizzata 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 di Workload Identity scarica periodicamente i metadati OIDC dal tuo provider di identità. La federazione di Workload Identity utilizza i metadati e il set di chiavi web JSON (JWKS) dell'IdP per convalidare i token.

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

Un malintenzionato potrebbe riuscire a sfruttare questa configurazione avviando un un attacco man in the middle (MITM), in cui riconfigurano il bilanciatore del carico consente di passare richieste JWKS a un endpoint dannoso che gestisce un insieme diverso di chiavi. Lo scambio di JWKS permette al malintenzionato di firmare token considerati valida dalla federazione delle identità per i carichi di lavoro e potrebbe consentire lo spoofing delle le identità di altro tipo.

Per proteggerti dallo scambio JWKS, assicurati che il deployment dell'IdP sia effettuato in modo lo protegge 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 segmento di pubblico dei token (codificato nella dichiarazione aud) corrisponda alla l'impostazione per il pubblico consentita del fornitore. Analogamente, quando esegui la federazione con un fornitore SAML, la federazione delle identità della forza lavoro controlla che l'affermazione SAML specifichi una limitazione del pubblico che corrisponda al pubblico previsto.

Per impostazione predefinita, la federazione delle identità per i carichi di lavoro prevede che il segmento di 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. Richiesta di token e asserzioni di utilizzare questo URL perché il pubblico aiuta a ridurre il rischio di vicepresidente confuso un attacco informatico. In questo tipo di attacco, un malintenzionato presenta a Workload Identity Federation un token o un'affermazione SAML che non era destinato a essere utilizzato per Workload Identity Federation, ma per un'altra API.

Richiedere che il token o l'asserzione contengano l'URL del carico di lavoro di destinazione il provider di pool di identità aiuta a garantire che i client possano utilizzare solo token e asserzioni emesse specificatamente per la federazione delle identità per i carichi di lavoro.

Utilizza attributi immutabili nelle mappature degli attributi

Per concedere a un'identità esterna l'autorizzazione a rubare l'identità di un account di servizio, crea un'associazione IAM che fa riferimento all'identità esterna in base a soggetto, gruppo o un attributo personalizzato. L'oggetto, il gruppo e gli attributi personalizzati dell'identità esterna sono derivati dagli attributi trasmessi dal provider di identità esterno Federazione delle identità per i carichi di lavoro durante lo scambio dei token.

Alcuni fornitori 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. Oppure, peggio ancora, i malintenzionati potrebbero riuscire ad accedere senza autorizzazione 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 agli attributi che non possono essere modificati dall'utente o non possono essere modificati.

Utilizza attributi non riutilizzabili nelle mappature degli attributi

Quando concedi a un'autorizzazione di identità esterna l'identità di un account di servizio e poi eliminare l'utente nel provider di identità esterno, dell'account di servizio rimane attivo.

Se in seguito aggiungi un nuovo utente al provider di identità esterno e l'utente condivide alcuni attributi con l'utente eliminato in precedenza (ad esempio, indirizzo email), il vecchio e il nuovo utente non saranno distinguibili Federazione delle identità per i carichi di lavoro. Di conseguenza, un'associazione IAM che doveva fare riferimento solo all'utente precedente potrebbe essere applicata anche al nuovo utente.

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

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

Non consentire la modifica delle mappature degli attributi

Utilizzi della federazione delle identità per i carichi di lavoro mappature degli attributi per selezionare gli attributi forniti dal provider di identità esterno devono essere incorporati in un token STS e come i nomi degli attributi traduci. La configurazione del mapping degli attributi è un passaggio fondamentale per la configurazione dell'attendibilità la relazione tra il provider di identità esterno e Google Cloud.

Le mappature degli attributi sono fondamentali anche per la sicurezza dell'utilizzo della federazione Workload Identity: se hai concesso a un'entità federata o all'entità impostato la possibilità di rubare l'identità di un account di servizio e poi modifichi la mappatura degli attributi, potresti modificare gli utenti che hanno accesso all'account di servizio.

Per modificare le mappature degli attributi è necessaria l'autorizzazione iam.googleapis.com/workloadIdentityPoolProviders.update. Ruoli che contengono questa autorizzazione includono:

• Proprietario (roles/owner)
• IAM Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin)

Se un utente malintenzionato è autorizzato a modificare le mappature degli attributi, potrebbe riuscire a di modificare le regole di mappatura in modo da poter falsificare la propria identità e accedere a un account di servizio. Per evitare queste modifiche dannose, assicurati che solo alcuni utenti amministrativi abbiano l'autorizzazione per modificare le mappature degli attributi.

Valuta la possibilità di creare un progetto Google Cloud dedicato per la gestione dei carichi di lavoro pool di identità, con cui puoi limitare il rischio che gli utenti vengano inavvertitamente uno di questi ruoli a un livello superiore nella gerarchia delle risorse.

Non fare affidamento su attributi che non sono stabili o autorevoli

Un provider di identità utilizza gli attributi per comunicare informazioni sugli utenti autenticati. In genere, i fornitori di servizi di identità garantiscono che alcuni attributi sono autorevoli, ma altri no. Ad esempio, un utente esterno il provider di identità potrebbe incorporare un nome utente e un ID utente in un token OIDC. Entrambi gli attributi identificano univocamente 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 che non sono stabili o una persona potrebbe essere in grado di falsificare la propria identità Modificando il proprio profilo utente nel provider di identità esterno. Ad esempio: potrebbe cambiare il proprio nome utente con quello di un utente che è stato quest'ultimo eliminato nel provider di identità esterno, ma che continua ad avere accesso a un servizio su Google Cloud.

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

Protezione dalle minacce di non ripudio

Ogni volta che noti attività sospette che interessano una delle tue risorse su Google Cloud, Cloud Audit Logs è 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 servizio . In Cloud Audit Logs, qualsiasi attività eseguita dall'applicazione viene attribuiti all'account di servizio impersonato. 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 quali dell'identità e del motivo per cui è stata svolta un'attività.

Questa sezione descrive le best practice che possono aiutarti a mantenere una tracciabilità non contestabile.

Best practice:

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

Abilita i log di accesso ai dati per le API IAM

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

Non tutti i servizi includono i dettagli di furto d'identità negli audit log di Cloud. Per aiutare deve mantenere un audit trail non ripudiabile, devi anche registrare tutti i eventi attivando i log di accesso 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 oppure account di servizio utilizzati per la federazione delle identità per i carichi di lavoro.

Se attivi questi log, ti assicuri che venga aggiunta una voce ai log di controllo di Cloud ogni volta che un'applicazione utilizza la federazione delle identità per i carichi di lavoro per scambiare una credenziale esterna e finge di essere un account di servizio.

Utilizza una mappatura dell'oggetto univoca

L'oggetto dell'entità utilizzato nella sezione serviceAccountDelegationInfo in Le voci di Cloud Audit Logs sono determinate dal provider del pool di identità per i carichi di lavoro mappatura degli attributi per google.subject.

Quando rilevi attività sospette e devi identificare l'identità esterna è coinvolto, devi essere in grado di cercare un'identità esterna in base Valore google.subject.

Analogamente, quando un'identità esterna è stata compromessa e occorre scoprire se l'identità è stata utilizzata per accedere alle risorse Google Cloud, individuare 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 esattamente a un valore google.subject.
• Un valore google.subject viene mappato a una sola identità esterna.
• Puoi cercare un'identità esterna in base al valore google.subject.

L'utilizzo di una mappatura degli attributi che soddisfi questi criteri di univocità ti aiuta assicurati di poter cercare le identità esterne in base al valore google.subject, e google.subject in base alle rispettive identità esterne.

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 rubare l'identità di un account di servizio
• limitare le risorse a cui un account di servizio può accedere

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

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

Best practice:

Utilizza account di servizio che si trovano nello stesso progetto delle risorse a cui devi accedere.
Utilizza 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 hai bisogno di accedere

Quando un client utilizza la federazione delle identità di carico di lavoro utilizzando le librerie client o l'API REST, segue una procedura in tre passaggi:

1. Ottieni una credenziale dal provider di identità attendibile.
2. Scambia la credenziale con un token del servizio token di sicurezza.
3. Utilizza il token del servizio token di sicurezza per impersonare un servizio e ottenere un token di accesso Google di breve durata.

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

Utilizza 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 di risorse nello stesso progetto, crea un account di servizio dedicato un'applicazione. L'utilizzo di account di servizio specifici per l'applicazione ti consente di evitare di concedere troppe autorizzazioni concedendo l'accesso solo 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 concedigli il ruolo roles/iam.workloadIdentityUser nell'account di servizio. Quando concedi non concederlo a tutti i membri del pool di identità per i carichi di lavoro. Invece, concedere il ruolo a identità esterne specifiche o a identità che corrispondono determinati criteri.

Inizialmente, il numero di utenti esterni che devono 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à potrebbe consentire solo per utilizzare la federazione delle identità per i carichi di lavoro.

Quando in un secondo momento esegui l'onboarding di nuovi carichi di lavoro in Google Cloud, potrebbe essere necessario modificare la configurazione del provider di identità o la condizione dell'attributo del pool di identità del carico di lavoro in modo da consentire identità esterne aggiuntive.

Concedendo il ruolo roles/iam.workloadIdentityUser solo a utenti esterni specifici di identità, puoi garantire la crescita sicura di un pool di identità per i carichi di lavoro senza aver concesso inavvertitamente un numero maggiore di accessi alla rappresentazione delle identità esterne necessaria.

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.