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

La federazione delle identità per i workload consente alle applicazioni in esecuzione all'esterno di Google Cloud di simulare l'identità di un account di servizio utilizzando le credenziali di un provider di identità esterno.

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

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

• Spoofing: un malintenzionato potrebbe tentare di rubare l'identità di un altro utente per ottenere l'accesso non autorizzato alle risorse Google Cloud .
• Escalation dei privilegi: un malintenzionato potrebbe sfruttare la federazione delle identità per i workload per ottenere l'accesso a risorse a cui altrimenti non avrebbe accesso.
• Non ripudio: un malintenzionato potrebbe nascondere la propria identità e le proprie azioni utilizzando credenziali esterne che rendono difficile risalire alle azioni.
• Configurazioni di credenziali dannose: un malintenzionato potrebbe fornire una configurazione di credenziali dannosa per aggirare le tue difese di sicurezza.

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

Quando utilizzare la federazione delle identità per i workload

Best practice:

Utilizza la federazione delle identità per i workload per le applicazioni che hanno accesso alle credenziali ambientali.
Utilizza uno scambio di token aggiuntivo per utilizzare le credenziali ambientali non supportate dalla federazione delle identità per i workload.
Utilizza la federazione delle identità per i workload per ridurre il numero di credenziali che richiedono la rotazione.

Utilizza la federazione delle identità per i workload per le applicazioni che hanno accesso alle credenziali ambientali

Le applicazioni in esecuzione su provider cloud diversi da Google Cloud spesso hanno accesso alle credenziali ambientali. Si tratta di credenziali che l'applicazione può ottenere senza dover eseguire ulteriori autenticazioni. 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.
• In Azure, le applicazioni possono utilizzare le identità gestite per ottenere token di accesso.
• In GitHub Actions, i workflow possono ottenere token ID che riflettono l'identità del job di deployment.

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

Utilizza la federazione delle identità per i workload ogni volta che un'applicazione deve accedere aGoogle Cloud e ha accesso alle credenziali ambientali.

Utilizza uno scambio di token aggiuntivo per utilizzare le credenziali ambientali non supportate dalla federazione delle identità per i workload

In alcuni casi, un'applicazione potrebbe avere accesso alle credenziali ambient, ma i tipi di credenziali non sono supportati dalla federazione delle identità per i workload. In questi casi, controlla se uno scambio di token aggiuntivo ti consente di convertire la credenziale ambientale in un tipo di credenziale che puoi utilizzare per la federazione delle identità per i workload.

Ad esempio, se la tua applicazione viene eseguita in un ambiente Active Directory, potrebbe avere accesso alle credenziali Kerberos. Se nel tuo ambiente hai un provider di identità come Active Directory Federation Services (AD FS) che supporta l'autenticazione integrata di Windows, puoi utilizzare queste credenziali Kerberos per autenticarti presso il provider di identità e ottenere un token di accesso OAuth che utilizza il formato JWT. Utilizzando questo token di accesso e la federazione delle identità per i workload, 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, ma può liberarti dalla necessità di gestire e proteggere le chiavi dei account di servizio.

Utilizza la federazione delle identità per i workload 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 un'altra forma di secret) per l'autenticazione con il provider di identità. In genere, questo secret viene archiviato come parte della configurazione dell'applicazione. Per consentire a un'applicazione di questo tipo di accedere a Google Cloud, devi scegliere tra:

1. Creazione di una chiave account di servizio e archiviazione insieme all'altro secret.
2. Utilizzando i token emessi dal provider di identità esistente e scambiandoli con le credenziali Google tramite la federazione delle identità per i workload.

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

Utilizza la federazione delle identità per i workload con endpoint regionali per soddisfare i requisiti di residenza dei dati

Se hai requisiti di residenza dei dati e devi controllare la regione in cui potrebbero verificarsi gli scambi di token, configura i tuoi workload in modo che utilizzino un endpoint regionale di Secure Token Service (STS).

Per generare un file di configurazione delle credenziali che utilizza un endpoint STS regionale, utilizza il comando gcloud iam workload-identity create-cred-config e aggiungi l'argomento --sts-location=REGION.

Per aggiornare un file di configurazione delle credenziali esistente, segui questi passaggi:

1. Apri il file di configurazione delle credenziali.
2. Nel campo token_url, sostituisci https://sts.googleapis.com con https://sts.REGION.rep.googleapis.com o, se utilizzi mTLS, sostituisci https://sts.mtls.googleapis.com con https://sts.REGION.rep.mtls.googleapis.com.

Per utilizzare gli endpoint regionali su Private Service Connect, consulta Informazioni sull'accesso agli endpoint regionali tramite gli endpoint di Private Service Connect.

Protezione dalle minacce di spoofing

Un pool di identità del workload non contiene identità o account utente, il che lo rende diverso da una directory utente come Cloud Identity. Invece, un pool di identità del workload rappresenta una vista 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à del workload 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 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 quando esegui la federazione con GitHub o altri provider di identità multi-tenant.
Utilizza un progetto dedicato per gestire i pool di identità del workload e i provider.
Utilizza i vincoli delle policy dell'organizzazione per disabilitare la creazione di provider di pool di identità del workload in altri progetti.
Utilizza un singolo provider per pool di identità del workload per evitare collisioni tra i 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à del workload 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 che non sono stabili o autorevoli.
Convalida le configurazioni delle credenziali da una fonte esterna prima di utilizzarle per l'autenticazione alle API di Google.

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

La federazione delle identità per i workload non gestisce una directory degli account utente, ma implementa identità basate su attestazioni: di conseguenza, quando due token vengono emessi dallo stesso provider di identità (IdP) e le relative attestazioni vengono 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 workload ispeziona e verifica l'URL dell'emittente del token.

Alcuni provider, come GitHub e Terraform Cloud, utilizzano un singolo URL emittente per tutti i tenant. Per questi provider, l'URL dell'emittente identifica tutto 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 workload di controllare l'URL dell'emittente di un token per assicurarsi che provenga da una fonte attendibile e che le sue rivendicazioni siano attendibili. Ti consigliamo di configurare una condizione dell'attributo di federazione delle identità per i workload per verificare che il token provenga da un tenant attendibile o, nel caso di GitHub o Terraform Cloud, da un'organizzazione attendibile.

Per saperne di più, consulta Configura una condizione degli attributi.

Utilizza un progetto dedicato per gestire i pool di identità del workload e i provider

Anziché gestire i pool di identità del workload e i provider in più progetti, utilizza un unico progetto dedicato per gestire i pool di identità del workload e i provider. 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 workload.
• Controlla centralmente l'accesso alla configurazione dei pool di identità del workload e dei provider.
• Applica mappature e condizioni degli attributi coerenti in tutti i progetti e le applicazioni.

Puoi utilizzare i vincoli delle policy dell'organizzazione per applicare la disciplina dell'utilizzo di un progetto dedicato per gestire i pool di identità del workload e i provider.

Utilizza i vincoli delle policy dell'organizzazione per disabilitare la creazione di provider di pool di identità del workload in altri progetti

Gli utenti con l'autorizzazione per creare provider di pool di identità del workload possono creare pool di identità del workload e provider che potrebbero essere ridondanti rispetto a quelli che gestisci in un progetto dedicato.

Puoi impedire la creazione di nuovi provider di pool di identità del workload utilizzando il vincolo della policy dell'organizzazione constraints/iam.workloadIdentityPoolProviders con un set di regole impostato su Nega tutto.

Applica questi vincoli alla radice della gerarchia organizzativa per negare la creazione di nuovi provider di pool di identità del workload per impostazione predefinita. Crea eccezioni per i progetti in cui vuoi consentire la gestione dei pool di identità del workload e dei provider applicando un vincolo della policy che consenta determinati account AWS o provider OIDC attendibili.

Utilizza un singolo provider per pool di identità del workload per evitare collisioni di soggetti

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

L'utilizzo di più provider introduce il rischio di collisioni di 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 una collisione di questo tipo è che più identità esterne vengono mappate alla stessa entità IAM, rendendo le identità esterne indistinguibili in Cloud Audit Logs.

Per evitare conflitti di soggetti, utilizza un singolo provider per pool di identità del workload. Se devi eseguire la federazione con più provider, crea più pool di identità del workload, ognuno dei quali utilizza un singolo provider di identità del workload.

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

Puoi creare più provider di pool di identità del workload che fanno riferimento allo stesso provider di identità o account AWS. Tuttavia, se questi provider appartengono allo stesso pool di identità del workload, questa configurazione può portare a collisioni dei soggetti. Se i provider appartengono a pool di identità del workload diversi, non possono verificarsi collisioni di soggetti e la stessa identità esterna viene rappresentata come entità IAM diverse.

La mappatura di una singola identità esterna a più entità IAM rende più difficile analizzare a quali risorse ha accesso una determinata identità esterna. Questa ambiguità può anche aumentare il rischio quando si tenta di revocare l'accesso: un amministratore potrebbe revocare l'accesso per un'entità, ma potrebbe non essere a conoscenza dell'esistenza di un'altra entità, causando inavvertitamente la conservazione dell'accesso da parte dell'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à del workload e un provider e utilizza una mappatura e una condizione degli attributi che ne 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 workload scarica periodicamente i metadati OIDC dal tuo provider di identità. La federazione delle identità per i workload 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 tuo provider è distribuito dietro un bilanciatore del carico o un reverse proxy che termina TLS, la connessione TLS garantisce l'autenticità del bilanciatore del carico o del reverse proxy, ma non dell'identity provider effettivo.

Un malintenzionato potrebbe sfruttare questa configurazione lanciando un attacco man-in-the-middle (MITM) in cui riconfigura il bilanciatore del carico per consentirgli di trasmettere le richieste JWKS a un endpoint dannoso che fornisce un insieme di chiavi diverso. Lo scambio del JWKS consente a un malintenzionato di firmare token considerati validi dalla federazione delle identità per i workload e potrebbe consentirgli di simulare l'identità di altri utenti.

Per proteggerti dallo scambio di JWKS, assicurati che il tuo IdP sia distribuito in modo da proteggerlo dagli attacchi MITM.

Utilizza l'URL del provider di pool di identità del workload come pubblico

Quando esegui la federazione con un provider OpenID Connect, la federazione delle identità per i workload verifica che il pubblico dei token (codificato nell'attestazione aud) corrisponda all'impostazione del pubblico consentito del provider. Analogamente, quando esegui la federazione con un provider SAML, la federazione delle identità per i workload verifica che l'asserzione SAML specifichi una limitazione del pubblico corrispondente al pubblico previsto.

Per impostazione predefinita, la federazione delle identità per i workload 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 di pool di identità del workload. La richiesta di token e asserzioni per utilizzare questo URL come segmento di pubblico contribuisce a ridurre il rischio di un attacco confused deputy. In un attacco di questo tipo, un malintenzionato presenta alla federazione delle identità per i workload un token o un'asserzione SAML che non era destinata a essere utilizzata per la federazione delle identità per i workload, ma per un'altra API.

Se richiedi che il token o l'asserzione contengano l'URL del provider del pool di identità del workload di destinazione, puoi assicurarti che i client possano utilizzare solo token e asserzioni emessi specificamente per la federazione delle identità per i workload.

Utilizza attributi immutabili nelle mappature degli attributi

Per concedere a un'identità esterna l'autorizzazione per simulare l'identità di un service account, devi creare un'associazione IAM che faccia riferimento all'identità esterna per soggetto, gruppo o attributo personalizzato. Gli attributi soggetto, gruppo e personalizzati dell'identità esterna derivano dagli attributi che il provider di identità esterno passa alla federazione delle identità dei workload durante lo scambio di 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 i propri 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, utenti malintenzionati potrebbero ottenere l'accesso non autorizzato ad altre risorse modificando deliberatamente i propri attributi utente in modo che corrispondano alle associazioni IAM esistenti.

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

Utilizza attributi non riutilizzabili nelle mappature degli attributi

Quando concedi a un'identità esterna l'autorizzazione per simulare l'identità di un account di servizio ed elimini l'utente nel provider di identità esterno, l'associazione IAM del account di servizio rimane attiva.

Se in un secondo momento aggiungi un nuovo utente al tuo provider di identità esterno e l'utente condivide determinati attributi con l'utente eliminato in precedenza (ad esempio, lo stesso indirizzo email), gli utenti precedenti e quelli nuovi non saranno distinguibili per la federazione delle identità per i workload. Di conseguenza, un'associazione IAM che doveva fare riferimento solo al vecchio utente 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, come un ID utente univoco.

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

Non consentire la modifica delle mappature degli attributi

La federazione delle identità per i workload utilizza le mappature degli attributi per selezionare quali attributi forniti dal provider di identità esterno devono essere incorporati in un token STS e come devono essere tradotti i nomi degli attributi. La configurazione delle mappature degli attributi è un passaggio fondamentale per configurare la relazione di trust 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 workload: se hai concesso a un'entità federata o a un set di entità la possibilità di simulare l'identità di un service account e poi modifichi la mappatura degli attributi, potresti modificare gli utenti che hanno accesso al account di servizio.

La modifica delle mappature degli attributi richiede l'autorizzazione iam.googleapis.com/workloadIdentityPoolProviders.update. I ruoli che contengono questa autorizzazione includono:

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

Se un malintenzionato dispone dell'autorizzazione per modificare le mappature degli attributi, potrebbe essere in grado di modificare le regole di mappatura in modo da falsificare la propria identità e ottenere l'accesso a un account di servizio. Per evitare queste modifiche dannose, assicurati che solo pochi utenti amministrativi dispongano dell'autorizzazione per modificare le mappature degli attributi.

Valuta la possibilità di creare un progetto Google Cloud dedicato per la gestione dei pool di identità del workload, in modo da limitare il rischio che agli utenti venga concesso inavvertitamente uno di questi ruoli a un livello superiore della 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 provider di identità garantiscono che alcuni attributi sono autorevoli, ma altri no. 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 essere in grado di falsificare la propria identità modificando il proprio profilo utente nel provider di identità esterno. Ad esempio, potrebbero modificare il proprio nome utente in quello di un utente che è stato eliminato di recente nel provider di identità esterno, ma che ha ancora accesso a un service account su Google Cloud.

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

Convalida le configurazioni delle credenziali da un'origine esterna prima di utilizzarle per l'autenticazione alle API di Google

Alcune configurazioni delle credenziali contengono URL e percorsi file che, se non convalidati in modo appropriato da un workload, potrebbero indurre il workload a utilizzare endpoint dannosi.

Quando accetti una configurazione delle credenziali da una fonte esterna, devi convalidare il JSON prima di utilizzarlo. Se non convalidi la configurazione delle credenziali, un malintenzionato potrebbe utilizzarla per fare in modo che il tuo workload acceda a endpoint dannosi.

Per saperne di più, consulta Requisiti di sicurezza per l'utilizzo delle configurazioni delle credenziali da un'origine esterna.

Protezione dalle minacce di non ripudio

Ogni volta che noti un'attività sospetta che interessa una delle tue risorse suGoogle 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 workload, simula l'identità di un service account. In Cloud Audit Logs, qualsiasi attività eseguita dall'applicazione viene attribuita al account di servizio di cui è stata eseguita la simulazione. Per ricostruire la catena completa 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 scoprire quale identità esterna è stata coinvolta e perché è stata eseguita un'attività.

Questa sezione descrive le best practice che possono aiutarti a mantenere una traccia di audit non ripudiabile.

Best practice:

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

Abilita i log di accesso ai dati per le API IAM

Per aiutarti a identificare e comprendere gli scenari di simulazione dell'identità dei 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 workload, questa sezione include l'oggetto dell'entità utilizzata per simulare l'identità del account di servizio.

Non tutti i servizi includono i dettagli di impersonificazione in Cloud Audit Logs. Per contribuire a mantenere una traccia di audit non ripudiabile, devi anche registrare tutti gli eventi di impersonificazione 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à del workload o service account utilizzati per la federazione delle identità per i workload.

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 workload per scambiare una credenziale esterna e simulare l'identità di un service account.

Utilizza una mappatura dei soggetti univoca

Il soggetto principale utilizzato nella sezione serviceAccountDelegationInfo nelle voci di log di Cloud Audit Logs è determinato dalla mappatura degli attributi del provider del pool di identità del workload per google.subject.

Quando rilevi un'attività sospetta e devi scoprire quale identità esterna è stata coinvolta, devi essere in grado di cercare un'identità esterna in base al valore google.subject corrispondente.

Analogamente, se un'identità esterna è stata compromessa e devi scoprire se è 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à del workload, 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 esattamente a un'identità esterna.
• Puoi cercare un'identità esterna in base al suo valore google.subject.

L'utilizzo di una mappatura degli attributi che soddisfa questi criteri di unicità ti aiuta a garantire che tu possa cercare le identità esterne in base al loro valore google.subject e i valori google.subject in base alle loro identità esterne.

Protezione dalle minacce di escalation dei privilegi

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

• limitare il numero di identità esterne che possono impersonare 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 fare l'escalation dei 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 service account 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.

Utilizza i service account che si trovano nello stesso progetto delle risorse a cui devi accedere

Quando un client utilizza la federazione delle identità per i workload 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 di Security Token Service.
3. Utilizza il token di Security Token Service per simulare l'identità di un service account e ottenere un token di accesso Google di breve durata.

Per l'ultimo passaggio, utilizza un account di servizio che si trova 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 il 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 workload per accedere alle risorse nello stesso progetto, crea un account di servizio dedicato per ogni applicazione. L'utilizzo di service account specifici per l'applicazione ti aiuta a evitare l'assegnazione di autorizzazioni eccessive 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 concederle il ruolo roles/iam.workloadIdentityUser sul service account. Quando concedi questo ruolo, evita di concederlo a tutti i membri del pool di identità del workload. Concedi invece il ruolo a identità esterne specifiche o a identità che corrispondono a determinati criteri.

Inizialmente, il numero di utenti esterni che devono accedere alle risorse Google Cloud potrebbe essere ridotto. La condizione dell'attributo del pool di identità del workload e la configurazione del provider di identità potrebbero quindi consentire solo ad alcune identità esterne di utilizzare la federazione delle identità per i workload.

Quando in un secondo momento esegui l'onboarding di nuovi workload in Google Cloud, potresti dover modificare la configurazione del provider di identità o la condizione dell'attributo del pool di identità del workload in modo da consentire identità esterne aggiuntive.

Concedendo il ruolo roles/iam.workloadIdentityUser solo a identità esterne specifiche, puoi assicurarti di poter far crescere in sicurezza un pool di identità del workload senza concedere inavvertitamente l'accesso per la simulazione dell'identità a più identità esterne del necessario.

Passaggi successivi

• Scopri le best practice per l'utilizzo dei service account.
• Scopri di più sulle best practice per la gestione account di servizio account.