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 in esecuzione al di fuori 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ò aiutarti 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 di Google Cloud .
  • Elevazione dei privilegi:un 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 ripudio:un malintenzionato potrebbe nascondere la propria identità e le proprie azioni utilizzando credenziali esterne che rendono difficile risalire alle azioni che ha compiuto.
  • Configurazioni di credenziali dannose:un malintenzionato potrebbe fornire una configurazione di credenziali dannose per aggirare le tue difese di sicurezza.

Questa guida presenta 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 alle credenziali ambientali.
Utilizza uno scambio di token aggiuntivo per utilizzare le credenziali ambientali non supportate dalla federazione di Workload Identity.
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 cloud provider diversi da Google Cloud spesso hanno accesso alle 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 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 flussi di lavoro 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 scambiarle con un token OIDC o un'asserzione SAML e poi utilizzarle per la federazione delle identità dei 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 ambientali.

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

In alcuni casi, un'applicazione potrebbe avere accesso alle credenziali ambientali, ma i tipi di credenziali non sono supportati dalla federazione delle identità dei carichi di lavoro. In questi casi, verifica se un ulteriore scambio di token ti consente di convertire la credenziale ambient in un tipo di credenziale che puoi utilizzare per la federazione delle identità per i carichi di lavoro.

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 l'autenticazione al 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 quindi 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 dipendenze aggiuntive, ma può liberarti dalla necessità di gestire e proteggere le chiavi del 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 un'altra forma di secret) per l'autenticazione al provider di identità. In genere, questo secret viene memorizzato 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 dell'account di servizio e memorizzazione insieme all'altro secret.
  2. Utilizzando i token emessi dal provider di identità esistente e scambiandoli con le credenziali Google utilizzando la federazione delle identità per i workload.

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, che a sua volta può contribuire a migliorare la sicurezza.

Utilizzo di endpoint del servizio token di sicurezza regionali per una maggiore affidabilità

Gli endpoint del servizio token di sicurezza regionale sono disponibili per Google Cloud in ogni regione.

Gli endpoint del servizio token di sicurezza regionale ti consentono di controllare dove avviene lo scambio di token, il che può migliorare le prestazioni e l'affidabilità, se segui le linee guida riportate in Progettare un'infrastruttura affidabile per i carichi di lavoro. Per utilizzare gli endpoint regionali, puoi utilizzare https://sts.REGION.rep.googleapis.com. Le regioni possono essere recuperate dal documento di rilevamento con il seguente comando. Puoi trovarli nel campo della posizione nella sezione Endpoints.

curl 'https://sts.googleapis.com/$discovery/rest'

Se utilizzi un file di configurazione delle credenziali per l'autenticazione, ad esempio uno scaricato dalla console Google Cloud , puoi procedere nel seguente modo:

  1. Modifica il file scaricato.
  2. Nel campo token_url, sostituisci https://sts.googleapis.com con https://sts.REGION.rep.googleapis.com.

Se utilizzi il comando gcloud iam workload-identity create-cred-config per generare il file di configurazione delle credenziali, utilizza il flag --sts-location=REGION. Ad esempio, se imposti REGION su us-central1, il clientGoogle Cloud utilizzerà https://sts.us-central1.rep.googleapis.com per acquisire i token correlati. Se --sts-location non è impostato o è impostato su global, viene utilizzato il dominio endpoint predefinito, https://sts.googleapis.com.

Puoi utilizzare gli URL degli endpoint regionali con Private Service Connect. Per maggiori informazioni sugli URL degli endpoint, consulta Informazioni sull'accesso agli endpoint regionali tramite gli endpoint 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 utenti come Cloud Identity. Un pool Workload Identity rappresenta invece una visualizzazione che mostra le identità di provider di identità esterni in modo che possano essere utilizzate come entità IAM.

A seconda di come configuri il pool Workload Identity e i relativi provider, la stessa identità esterna potrebbe essere rappresentata come più entità IAM diverse oppure diverse identità esterne potrebbero essere mappate alla stessa entità IAM. Queste ambiguità potrebbero consentire ai 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 provider e i pool di identità del workload.
Utilizza i vincoli dei criteri dell'organizzazione per disattivare la creazione di fornitori del pool di identità del workload in altri progetti.
Utilizza un singolo fornitore per ogni pool di identità del workload per evitare collisioni di soggetti.
Evita 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 fornitore 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 non stabili o autorevoli.

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

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

Alcuni provider, come GitHub e Terraform Cloud, utilizzano un unico URL emittente in tutti i loro 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 carichi di lavoro di controllare l'URL dell'emittente di un token per assicurarsi che provenga da un'origine 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 provenga da un tenant attendibile o, nel caso di GitHub o Terraform Cloud, da un'organizzazione attendibile.

Per saperne di più, consulta Configurare una condizione dell'attributo.

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

Anziché gestire i pool e i provider di identità del workload in più progetti, utilizza un singolo progetto dedicato per gestire i pool e i provider di identità del workload. L'utilizzo di un progetto dedicato ti consente di:

  • Assicurati che per la federazione delle identità per i workload vengano utilizzati solo provider di identità attendibili.
  • Controlla centralmente l'accesso alla configurazione dei provider e dei 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 imporre l'utilizzo di un progetto dedicato per gestire i pool e i provider di identità del workload.

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

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

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

Applica questi vincoli alla radice della gerarchia organizzativa per negare la creazione di nuovi fornitori di pool di identità del workload per impostazione predefinita. Crea eccezioni per i progetti in cui vuoi consentire la gestione di pool e provider di identità per i carichi di lavoro applicando un vincolo di policy che consente 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à del 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 carichi di lavoro 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à dei carichi di lavoro, ognuno dei quali utilizza un singolo provider di identità dei carichi di lavoro.

Evitare 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à del workload che utilizzano la stessa configurazione o una configurazione simile. Se questi provider appartengono allo stesso pool di identità del workload, una configurazione di questo tipo può portare a collisioni di soggetti. Se i provider appartengono a pool di identità del workload diversi, non possono verificarsi collisioni di 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 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 il mantenimento dell'accesso per l'identità esterna.

Per ridurre al minimo il rischio di ambiguità, evita di federare più volte lo stesso provider di identità. Crea invece un unico pool e provider Workload Identity e utilizza una mappatura e una condizione degli attributi che garantiscano che possa essere utilizzato per tutte le identità esterne che richiedono l'accesso alle risorse Google Cloud .

Proteggere l'endpoint dei metadati OIDC del provider di identità

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

Per garantire l'autenticità, la comunicazione con il tuo provider di identità è protetta tramite TLS. Se il tuo provider è implementato 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 essere in grado di sfruttare questa configurazione lanciando un attacco man-in-the-middle (MITM) in cui riconfigura il bilanciatore del carico per consentirgli di passare le richieste JWKS a un endpoint dannoso che serve un insieme diverso di chiavi. Lo scambio di JWKS consente a un malintenzionato di firmare token considerati validi dalla federazione delle identità per i carichi di lavoro e potrebbe consentirgli di falsificare le identità di altri utenti.

Per proteggerti dallo scambio di JWKS, assicurati che il tuo IdP sia implementato in modo da proteggerti 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à del 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à del workload verifica che l'asserzione 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 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. Richiedere token e asserzioni per utilizzare questo URL come pubblico contribuisce a ridurre il rischio di un attacco confused deputy. In questo tipo di attacco, un malintenzionato presenta un token o un'asserzione SAML alla federazione delle identità dei carichi di lavoro che non era destinato a essere utilizzato per la federazione delle identità dei carichi di lavoro, ma per un'altra API.

Se richiedi che il token o l'asserzione contenga 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 carichi di lavoro.

Utilizzare attributi immutabili nelle mappature degli attributi

Per concedere a un'identità esterna l'autorizzazione a rappresentare un service account, crea un binding IAM che fa riferimento all'identità esterna per soggetto, gruppo o attributo personalizzato. Gli attributi personalizzati, il gruppo e il soggetto dell'identità esterna derivano dagli attributi che il provider di identità esterno passa a Workload Identity Federation durante lo scambio di token.

Alcuni provider di identità consentono agli utenti di modificare alcuni dei propri attributi. Ad esempio, a un utente potrebbe essere consentito di modificare il proprio indirizzo email o i propri alias. Se i binding IAM fanno riferimento ad attributi modificabili, gli utenti potrebbero perdere accidentalmente l'accesso a determinate risorse modificando il proprio profilo utente. O peggio ancora, gli 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 i mapping degli attributi a quelli che non possono essere modificati dall'utente o che non possono essere modificati affatto.

Utilizzare attributi non riutilizzabili nelle mappature degli attributi

Quando concedi a un'identità esterna l'autorizzazione a simulare l'identità di un account di servizio e successivamente elimini l'utente nel provider di identità esterno, l'associazione IAM delaccount di serviziot rimane invariata.

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 nuovi non saranno distinguibili per la federazione delle identità per i carichi di lavoro. Di conseguenza, un'associazione IAM che doveva riferirsi 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 norme della tua azienda consentono il riutilizzo di attributi come gli indirizzi email, evita di utilizzare questi attributi nei mapping degli attributi e utilizza un attributo diverso che sia garantito come univoco nel tempo.

Non consentire la modifica delle mappature degli attributi

Workload Identity Federation utilizza le mappature degli attributi per selezionare quali degli 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 impostare la relazione di trust tra il provider di identità esterno e Google Cloud.

I mapping 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 insieme di entità la possibilità di impersonare un service account e poi modifichi il mapping degli attributi, potresti modificare gli utenti che hanno accesso al account di servizio.

La modifica dei mapping 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 ha l'autorizzazione a modificare i mapping degli attributi, potrebbe essere in grado di modificare le regole di mapping in modo da falsificare la propria identità e ottenere l'accesso a uaccount di serviziont. Per evitare modifiche dannose di questo tipo, assicurati che solo pochi utenti amministrativi dispongano dell'autorizzazione per modificare i mapping degli attributi.

Valuta la possibilità di creare un progetto Google Cloud dedicato alla gestione dei pool di identità dei carichi di lavoro, che ti aiuta a limitare il rischio che agli utenti venga inavvertitamente concesso uno di questi ruoli a un livello superiore della 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à in genere garantiscono che alcuni attributi sono autorevoli, ma altri no. Ad esempio, un provider di identità esterno potrebbe incorporare sia un nome utente che 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 i mapping 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, potrebbe cambiare il proprio nome utente con quello di un utente eliminato di recente nel provider di identità esterno, ma che ha ancora accesso a un account di servizio su Google Cloud.

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

Protezione contro le minacce di non ripudio

Ogni volta che noti un'attività sospetta che interessa 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 di Workload Identity, simula l'identità di un service account. Nei log di controllo di Cloud, qualsiasi attività eseguita dall'applicazione è attribuita all'account di servizio rappresentato. 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 identity provider 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 di accesso ai dati per le API IAM.
Utilizza una mappatura degli argomenti univoca.

Abilitare i log di accesso ai dati per le API IAM

Per aiutarti a identificare e comprendere gli scenari di rappresentazione dell'identità del account di servizio, servizi come Compute Engine includono una sezione serviceAccountDelegationInfo in Cloud Audit Logs. Quando un'applicazione utilizza la federazione di Workload Identity, questa sezione include il soggetto del principal utilizzato per simulare l'identità deaccount di serviziont.

Non tutti i servizi includono i dettagli di rappresentazione in Cloud Audit Logs. Per contribuire a mantenere una traccia di controllo non ripudiabile, devi anche registrare tutti gli eventi di rappresentazione attivando i log di accesso ai dati per l'API Security Token Service e l'API Identity and Access Management. Attiva questi log per tutti i progetti Cloud che contengono pool di identità per i carichi di lavoro o service account utilizzati per la federazione delle identità per i carichi di lavoro.

Se attivi 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 impersonare un service account.

Utilizzare una mappatura dell'oggetto univoca

Il soggetto principale utilizzato nella sezione serviceAccountDelegationInfo delle voci di Cloud Audit Logs è determinato dal mapping degli attributi del provider del pool di identità per i carichi di lavoro per google.subject.

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

Allo stesso modo, quando 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 a esattamente un 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 unicità ti aiuta a assicurarti di poter 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 carichi di lavoro, devi:

  • limitare il numero di identità esterne che possono rappresentare 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 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 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 service account che si trovano 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 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 rappresentare 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 consente di applicare autorizzazioni di accesso più restrittive e semplifica la decisione su 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 carichi di lavoro per accedere alle risorse nello stesso progetto, crea un account di servizio dedicato per ogni applicazione. L'utilizzo di service account specifici per le applicazioni ti aiuta a evitare l'assegnazione eccessiva di 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 rappresentare 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 di Google Cloud potrebbe essere ridotto. Pertanto, la condizione dell'attributo del pool di identità dei carichi di lavoro e la configurazione del provider di identità potrebbero consentire solo a poche identità esterne di utilizzare la federazione delle identità per i workload.

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

Concedendo il ruolo roles/iam.workloadIdentityUser solo a identità esterne specifiche, puoi assicurarti di poter aumentare in modo sicuro un pool Workload Identity senza concedere inavvertitamente l'accesso alla rappresentazione di più identità esterne del necessario.

Protezione da configurazioni di credenziali dannose

Alcune configurazioni delle credenziali contengono URL e percorsi di file che, se non convalidati in modo appropriato da un workload, potrebbero causare l'utilizzo di endpoint dannosi.

Best practice:

Convalida le configurazioni delle credenziali da una fonte esterna prima di utilizzarle per l'autenticazione alle API di Google.

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

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 quando utilizzi configurazioni delle credenziali da un'origine esterna.

Passaggi successivi