Con la federazione delle identità per la forza lavoro, gli utenti del tuo IdP esterno possono utilizzare il Single Sign-On (SSO) per accedere alle risorse Google Cloud .
Che cos'è la federazione delle identità per la forza lavoro?
La federazione delle identità per la forza lavoro ti consente di utilizzare il tuo IdP esterno per autenticare la tua forza lavoro, ovvero utenti e gruppi di utenti, come dipendenti, partner e appaltatori. Gli utenti possono quindi accedere Google Cloud utilizzando Single Sign-On (SSO) tramite il tuo IdP. Utilizza le policy di autorizzazione per autorizzare gli utenti della tua forza lavoro ad accedere ai Google Cloud servizi.
Federazione e sincronizzazione
La federazione delle identità per la forza lavoro federa le identità dal tuo IdP, quindi non memorizza gli account utente in Google Cloud. Per questo motivo, la federazione delle identità per la forza lavoro non prevede la sincronizzazione, il che significa che non devi utilizzare strumenti per sincronizzare le identità utente dal tuo IdP con le identità gestite da Google che richiedono Account Google. Ad esempio, utilizzando la federazione delle identità per la forza lavoro, non è necessario utilizzare Google Cloud Directory Sync (GCDS) di Cloud Identity.
Per confrontare questo approccio con altre architetture di federazione, consulta Modelli di architettura per la federazione delle identità.
Federazione delle identità per la forza lavoro e federazione delle identità per i workload
La federazione delle identità per la forza lavoro federata le identità utente, mentre la federazione delle identità per i workload federa le identità dei workload.
Per ulteriori informazioni, consulta la pagina Federazione delle identità per i workload.
Accesso basato su attributi
La federazione delle identità della forza lavoro estende le funzionalità di identità di Google Cloudper supportare l'accesso basato sugli attributi. In alcuni IdP, gli attributi sono noti anche come attestazioni.
Dopo l'autenticazione dell'utente, gli attributi ricevuti dall'IdP vengono utilizzati per determinare l'ambito di accesso alle risorse Google Cloud .
Protocolli supportati
Puoi utilizzare la federazione delle identità per la forza lavoro con qualsiasi IdP che supporti OpenID Connect (OIDC) o SAML 2.0, come Microsoft Entra ID, Active Directory Federation Services (AD FS), Okta e altri.
Concetti fondamentali
Questa sezione descrive i concetti chiave della federazione delle identità per la forza lavoro.
Pool di identità della forza lavoro
I pool di identità della forza lavoro consentono di gestire gruppi di identità della forza lavoro e il loro accesso alle risorse Google Cloud .
I pool ti consentono di:
- Raggruppa le identità utente, ad esempio
employeesopartners. - Concedi l'accesso IAM a un intero pool o a un sottoinsieme del pool.
- Federare le identità da uno o più IdP.
- Definisci criteri su un gruppo di utenti che richiedono autorizzazioni di accesso simili.
- Specifica le informazioni di configurazione specifiche dell'IdP, tra cui la mappatura degli attributi e le condizioni degli attributi.
- Abilita l'accesso all'API e a Google Cloud CLI per le identità di terze parti.
- Registra l'accesso degli utenti all'interno di un pool in Cloud Audit Logs, insieme all'ID del pool.
Puoi creare più pool. Per un esempio che descrive un approccio di questo tipo, vedi Esempio: più pool di identità della forza lavoro.
I pool sono configurati a Google Cloud livello di organizzazione, il che motiva le seguenti considerazioni:
- Quando configuri per la prima volta la federazione delle identità per la forza lavoro per la tua organizzazione, fornisci un ID univoco per il pool. L'ID pool deve essere univoco a livello globale in tutti i pool di identità della forza lavoro in Google Cloude deve descrivere chiaramente le identità che contiene.
- Se disponi delle autorizzazioni IAM appropriate per visualizzare il pool, puoi farvi riferimento tramite il suo ID in tutti i progetti e le cartelle dell'organizzazione.
Provider di pool di identità della forza lavoro
Un provider di pool di identità della forza lavoro è un'entità che descrive una relazione tra la tua organizzazione Google Cloud e il tuo IdP.
La federazione delle identità per la forza lavoro segue la specifica di scambio di token OAuth 2.0 (RFC 8693). Fornisci una credenziale dal tuo IdP esterno al servizio token di sicurezza, che verifica l'identità nella credenziale e restituisce un token di accesso Google Cloud di breve durata in cambio.
Tipi di flusso OIDC
Per i provider OIDC, la federazione delle identità per la forza lavoro supporta sia il flusso del codice di autorizzazione sia il flusso implicito. Il flusso del codice di autorizzazione è considerato il più sicuro perché i token vengono restituiti dall'IdP in una transazione di backend separata e sicura, direttamente dall'IdP a Google Cloud, dopo l'autenticazione degli utenti. Di conseguenza, le transazioni del flusso di codice possono recuperare token di qualsiasi dimensione, in modo da avere più rivendicazioni da utilizzare per la mappatura degli attributi e la condizione degli attributi. Nel flusso implicito, invece, il token ID viene restituito dall'IdP al browser. I token sono soggetti ai limiti di dimensione degli URL dei singoli browser.
Quando utilizzi il flusso del codice di autorizzazione, puoi configurare il provider in modo da unire le rivendicazioni dell'endpoint OIDC UserInfo con le rivendicazioni del token ID (merge-user-info-over-id-token-claims) o includere solo le rivendicazioni del token ID (only-id-token-claims). Il flusso implicito supporta solo le rivendicazioni del token ID (only-id-token-claims).
Google Cloud Console della federazione delle identità per la forza lavoro
Gli utenti di un pool di identità della forza lavoro possono accedere alla Google Cloud console della federazione delle identità per la forza lavoro, nota anche come console (federata). La console fornisce a questi utenti l'accesso alla UI dei Google Cloud prodotti che supportano la federazione delle identità per la forza lavoro.
Attributi
L'IdP fornisce attributi, definiti da alcuni IdP come attestazioni. Gli attributi contengono informazioni sugli utenti. Puoi utilizzare questi attributi nelle mappature degli attributi e nelle condizioni degli attributi.
Mappature degli attributi
Puoi mappare questi attributi per l'utilizzo da parte di Google Cloud utilizzando Common Expression Language (CEL).
Questa sezione descrive l'insieme di attributi obbligatori e facoltativi forniti da Google Cloud .
Puoi anche definire attributi personalizzati nel tuo IdP che possono essere utilizzati da prodotti Google Cloud specifici, ad esempio nelle policy di autorizzazione IAM.
La dimensione massima per i mapping degli attributi è 16 KB. Se le dimensioni dei mapping degli attributi superano il limite di 16 KB, il tentativo di accesso non andrà a buon fine.
Gli attributi sono i seguenti:
google.subject(obbligatorio): un identificatore univoco per l'utente che esegue l'autenticazione. Spesso è l'asserzione del soggetto del JWT, perché i log di Cloud Audit Logs registrano i contenuti di questo campo come principal. Puoi utilizzare questo campo per configurare IAM per le decisioni di autorizzazione. Ti consigliamo di non utilizzare un valore modificabile perché se modifiche il valore nella directory utenti del tuo IdP, l'utente perde l'accesso.La lunghezza massima è di 127 byte.
google.groups(facoltativo): la raccolta di gruppi di cui fa parte l'utente che esegue l'autenticazione. Puoi configurare un'espressione logica utilizzando un sottoinsieme di CEL che produce un array di stringhe. Puoi anche utilizzare questo campo per configurare IAM per le decisioni di autorizzazione. Le limitazioni pergoogle.groupssono le seguenti:Ti consigliamo di limitare il nome del gruppo a 40 caratteri.
Se un singolo utente appartiene a più di 400 gruppi, il tentativo di accesso dell'utente non andrà a buon fine. Per risolvere questo problema, devi definire un insieme più piccolo di gruppi nell'asserzione e mappare solo i gruppi utilizzati per federare l'utente in Google Cloud.
Se utilizzi questo attributo per concedere l'accesso in IAM, a ogni membro dei gruppi mappati viene concesso l'accesso. Pertanto, ti consigliamo di assicurarti che solo gli utenti autorizzati della tua organizzazione possano modificare l'appartenenza ai gruppi mappati.
google.display_name(facoltativo): attributo utilizzato per impostare il nome dell'utente che ha eseguito l'accesso nella console Google Cloud . Questo attributo non può essere utilizzato nei criteri di autorizzazione IAM né nella condizione dell'attributo.La lunghezza massima è di 100 byte.
google.profile_photo(facoltativo): un URL della foto in miniatura dell'utente. Consigliamo una foto di 400 x 400 pixel. Quando questo attributo è impostato, l'immagine è visibile come immagine del profilo dell'utente nella console Google Cloud . Se questo valore non è impostato o non può essere recuperato, viene visualizzata un'icona utente generica. Questo attributo non può essere utilizzato nelle norme di autorizzazione IAM o nella condizione dell'attributo.google.posix_username(Facoltativo): una stringa di nome utente univoca conforme a POSIX utilizzata per quanto segue:Questo attributo non può essere utilizzato nelle policy di autorizzazione IAM o nella condizione dell'attributo. La lunghezza massima è di 32 caratteri.
google.email(facoltativo): un attributo utilizzato per mappare gli indirizzi email degli utenti federati che hanno eseguito l'accesso dall'IdP ai prodotti che integri utilizzando l'integrazione del client OAuth della federazione delle identità per la forza lavoro. Questo attributo non può essere utilizzato nelle policy di autorizzazione IAM o nella condizione dell'attributo.Ad esempio, per mappare gli indirizzi email da Okta utilizzando il protocollo OIDC, includi
google.email=assertion.emailnella mappatura degli attributi.Esempio Google Cloud i prodotti che supportano l'integrazione del client OAuth includono i seguenti:
attribute.KEY(Facoltativo): un attributo definito dall'IdP esterno presente nel token IdP di un utente. Puoi utilizzare l'attributo personalizzato per definire la strategia di autorizzazione in una policy di autorizzazione IAM.Ad esempio, nel tuo IdP puoi scegliere di definire un attributo come il centro di costo dell'utente come
costcenter = "1234"e poi fare riferimento al principal nel seguente modo:principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.costcenter/1234
Dopo aver concesso l'accesso alle risorse Google Cloud a questo identificatore dell'entità, tutte le identità configurate nel provider di identità per avere l'attributo
costcenterimpostato su1234hanno accesso alle risorse.Puoi configurare un massimo di 50 regole di mappatura degli attributi personalizzati. La dimensione massima di ciascuna regola è di 2048 caratteri.
Sebbene non vi siano restrizioni sugli attributi che puoi mappare qui, ti consigliamo vivamente di scegliere attributi i cui valori siano stabili. Ad esempio, un attributo come
attribute.job_descriptionpotrebbe cambiare per molti motivi (ad esempio per migliorarne la leggibilità). In alternativa, puoi utilizzareattribute.role. Le modifiche a quest'ultimo indicano un cambiamento di responsabilità assegnata e sono in linea con le modifiche all'accesso concesso all'utente.
Puoi trasformare i valori degli attributi utilizzando le funzioni CEL standard. Puoi anche utilizzare le seguenti funzioni personalizzate:
La funzione
splitdivide una stringa in base al valore separatore fornito. Ad esempio, per estrarre l'attributousernameda un attributo indirizzo email dividendo il relativo valore in corrispondenza di@e utilizzando la prima stringa, utilizza la seguente mappatura degli attributi:attribute.username=assertion.email.split("@")[0]La funzione
joinunisce un elenco di stringhe in base al valore del separatore fornito. Ad esempio, per compilare l'attributo personalizzatodepartmentconcatenando un elenco di stringhe con.come separatore, utilizza la seguente mappatura degli attributi:attribute.department=assertion.department.join(".")
Condizioni attributi
Le condizioni degli attributi sono espressioni CEL facoltative che consentono di impostare vincoli sugli attributi dell'identità accettati da Google Cloud .
I vantaggi dell'utilizzo delle condizioni degli attributi includono:
- Puoi utilizzare le condizioni degli attributi per consentire solo a un sottoinsieme di identità esterne di eseguire l'autenticazione sul tuo progetto Google Cloud . Ad esempio, potresti voler consentire l'accesso solo alle identità che fanno parte di un team specifico, soprattutto se utilizzi un IdP pubblico. Ad esempio, potresti voler consentire l'accesso al tuo team di contabilità, ma non al team di ingegneria.
- Le condizioni degli attributi ti consentono di impedire che le credenziali destinate all'uso con un'altra piattaforma vengano utilizzate con Google Cloude viceversa. In questo modo si evita il problema del vice confuso.
Condizioni degli attributi per IdP multi-tenant
La federazione delle identità della forza lavoro non gestisce una directory di account utente, ma implementa identità basate sulle rivendicazioni. Di conseguenza, quando due token vengono emessi dallo stesso IdP e le relative rivendicazioni 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 la forza lavoro ispeziona e
verifica l'URL emittente del token.
I provider di identità multi-tenant, come GitHub e Terraform Cloud, utilizzano un unico URL emittente in tutti i loro tenant. Per questi provider, l'URL emittente identifica l'intera organizzazione GitHub o Terraform Cloud, non una specifica organizzazione GitHub o Terraform Cloud.
Quando utilizzi questi IdP, non è sufficiente consentire alla federazione delle identità per la forza lavoro di controllare l'URL dell'emittente di un token per assicurarsi che provenga da una fonte attendibile e che le sue rivendicazioni siano attendibili. Se il tuo IdP multi-tenant ha un singolo URL emittente, devi utilizzare le condizioni degli attributi per assicurarti che l'accesso sia limitato al tenant corretto.
Audit logging dettagliato
Il logging di controllo dettagliato è una funzionalità della federazione delle identità per la forza lavoro che registra gli attributi ricevuti dall'IdP in Cloud Audit Logs.
Puoi attivare la registrazione dettagliata degli audit quando crei il provider del pool di identità della forza lavoro.
Per scoprire come risolvere i problemi relativi agli errori di mappatura degli attributi con la registrazione dettagliata del controllo, consulta Errori generali di mappatura degli attributi.
Chiavi web JSON
Il provider del pool di forza lavoro può accedere alle chiavi web JSON (JWK)
fornite dal tuo IdP nel campo jwks_uri del
documento /.well-known/openid-configuration. Se il tuo provider OIDC non
fornisce queste informazioni o se il tuo emittente non è accessibile pubblicamente, puoi
caricare manualmente i JWK quando crei o aggiorni il provider OIDC.
Supporto SCIM
Se il tuo IdP supporta System for Cross-domain Identity Management (SCIM), puoi configurarlo per eseguire il provisioning e gestire i gruppi in Google Cloud.
Per ulteriori informazioni, consulta Provisioning SCIM per la federazione delle identità per la forza lavoro e Configurare il provider di identità per Gemini Enterprise.
Identificatori delle entità della forza lavoro per le policy di autorizzazione
La seguente tabella mostra gli identificatori delle entità che puoi utilizzare per concedere ruoli a singoli utenti e gruppi di utenti.
| Identità | Formato dell'identificatore |
|---|---|
| Singola identità in un pool di identità della forza lavoro |
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
|
| Tutte le identità della forza lavoro in un gruppo |
principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
|
| Tutte le identità della forza lavoro con un valore di attributo specifico |
principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
|
| Tutte le identità in un pool di identità della forza lavoro |
principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*
|
Per un elenco completo degli identificatori delle entità, consulta Identificatori delle entità.
Altre considerazioni
Questa sezione descrive altre considerazioni da tenere presenti quando utilizzi la federazione delle identità per la forza lavoro.
Limitare l'accesso tra organizzazioni
Le entità del pool di identità della forza lavoro non possono accedere direttamente alle risorse al di fuori dell'organizzazione a cui appartengono. Tuttavia, se a un'entità viene concessa l'autorizzazione a simulare l'identità di un service account all'interno dell'organizzazione, questo vincolo può essere aggirato in quanto i service account non sono soggetti alle stesse limitazioni.
Progetto utente dei pool di forza lavoro
La maggior parte delle API Google Cloud (API basate sulle risorse) addebitano la fatturazione e la quota al progetto contenente la risorsa. Alcune API (API basate sul client) addebitano i costi al progetto associato al client, noto come progetto quota.
Quando crei un file di configurazione della federazione delle identità per la forza lavoro, specifichi un progetto utente dei pool di forza lavoro. Questo progetto identifica la tua
applicazione per le API di Google e funge da progetto di quota predefinito per
le API basate su client, a meno che tu non utilizzi gcloud CLI per effettuare la richiesta.
Devi disporre dell'autorizzazione serviceusage.services.use, inclusa nel
ruolo Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) per il
progetto specificato.
Per ulteriori informazioni sul progetto di quota, sulle API basate sulle risorse e sulle API basate sul client, consulta la panoramica del progetto di quota.
Esempio: più pool di identità della forza lavoro
Questa sezione contiene un esempio che illustra l'utilizzo tipico di più pool.
Puoi creare un pool per i dipendenti e un altro per i partner. Le organizzazioni multinazionali potrebbero creare pool separati per le diverse divisioni della loro organizzazione. I pool consentono la gestione distribuita, in cui gruppi diversi possono gestire in modo indipendente il proprio pool specifico in cui i ruoli vengono concessi solo alle identità nel pool.
Ad esempio, supponiamo che una società denominata Enterprise Example Organization
stipuli un contratto con un'altra società denominata Partner Example Organization Inc per fornire
servizi DevOps di Google Kubernetes Engine (GKE). Affinché la forza lavoro dell'organizzazione di esempio del partner possa fornire i servizi, deve essere autorizzata ad accedere a Google Kubernetes Engine (GKE) e ad altre risorse Google Cloud nell'organizzazione di esempio dell'organizzazione Enterprise. L'organizzazione Enterprise Example ha già
un pool di identità della forza lavoro chiamato enterprise-example-organization-employees.
Per consentire all'organizzazione di esempio del partner di gestire l'accesso alle risorse dell'organizzazione di esempio dell'impresa, quest'ultima crea un pool di forza lavoro separato per gli utenti della forza lavoro dell'organizzazione di esempio del partner, in modo che quest'ultima possa gestirlo. L'organizzazione di esempio Enterprise fornisce il pool di forza lavoro a un amministratore dell'organizzazione di esempio Partner. L'amministratore dell'organizzazione di esempio del partner utilizza il proprio IdP per concedere l'accesso alla propria forza lavoro.
Per farlo, l'amministratore dell'organizzazione di esempio Enterprise esegue le seguenti attività:
Crea un'identità come
partner-organization-admin@example.comper l'amministratore dell'organizzazione di esempio del partner nel provider di identità dell'organizzazione di esempio dell'azienda, che è già configurato nel pool denominatoenterprise-example-organization-employees.Crea un nuovo pool di forza lavoro denominato
example-organization-partner.Crea la seguente policy di autorizzazione per il pool
example-organization-partner:{ "bindings": [ { "role": "roles/iam.workforcePoolEditor", "members": [ "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com" ] } ] }Concedi ruoli per il pool
example-organization-partnersulle risorse a cui deve accedere nell'organizzazione dell'organizzazione di esempio Enterprise.
L'amministratore dell'organizzazione di esempio del partner può ora configurare il pool example-organization-partner per connettersi al proprio IdP. In questo modo, possono
consentire alla forza lavoro dell'organizzazione di esempio del partner di accedere con le credenziali dell'IdP dell'organizzazione di esempio del partner. Dopo aver eseguito l'accesso, gli utenti della forza lavoro dell'organizzazione di esempio del partner possono accedere alle risorse Google Cloud , vincolate dalle norme definite dall'organizzazione di esempio dell'impresa.
Best practice per i gruppi di sicurezza
Nelle grandi aziende, gli amministratori IT spesso creano gruppi di sicurezza nell'ambito di un modello di controllo dell'accesso basato sulle best practice. I gruppi di sicurezza regolano l'accesso alle risorse interne. Inoltre, le aziende spesso creano gruppi aggiuntivi per i dipendenti e altri gruppi per i partner per estendere questo modello di controllo dell'accesso alle risorse cloud. Ciò può comportare la proliferazione di gruppi nidificati in profondità che possono diventare molto difficili da gestire.
La tua organizzazione potrebbe anche avere criteri che limitano il numero di gruppi che puoi creare per mantenere la gerarchia della directory degli utenti ragionevolmente piatta. Una soluzione migliore per evitare errori di configurazione delle policy di autorizzazione e limitare la crescita dei gruppi è utilizzare più pool per creare una separazione più ampia degli utenti di diverse unità organizzative e unità aziendali, nonché delle organizzazioni partner. Puoi quindi fare riferimento a questi pool e gruppi contenuti al loro interno per definire le policy di autorizzazione (vedi gli esempi nel passaggio Configurazione di IAM). Per ulteriori consigli sulla governance dei gruppi e sulla gestione dei pool, consulta Best practice per l'utilizzo della federazione delle identità per la forza lavoro.
Limitazioni dei Controlli di servizio VPC
Le funzionalità amministrative della federazione delle identità per la forza lavoro, incluse le API di configurazione del pool della forza lavoro, non supportano i Controlli di servizio VPC. Tuttavia, Google Cloud i prodotti che supportano sia la federazione delle identità della forza lavoro sia i Controlli di servizio VPC funzionano come documentato e sono soggetti ai controlli delle policy dei Controlli di servizio VPC. Inoltre, puoi utilizzare identità di terze parti come utenti del pool di forza lavoro e identità del workload nelle regole in entrata o in uscita dei Controlli di servizio VPC.
Per le richieste API Security Token Service in cui il pubblico è un pool di federazione delle identità per la forza lavoro (che è una risorsa a livello di organizzazione), devi configurare le regole di uscita. Ciò è necessario perché Controlli di servizio VPC non supporta l'aggiunta diretta di risorse a livello di organizzazione ai perimetri. Le seguenti regole in uscita consentono alle richieste provenienti dal perimetro di raggiungere le API Workforce STS che interagiscono con i pool di forza lavoro a livello di organizzazione:
- egressTo:
operations:
- serviceName: 'sts.googleapis.com'
methodSelectors:
- method: '*'
resources:
- '*'
egressFrom:
identityType: ANY_IDENTITY
Federazione delle identità per la forza lavoro e contatti fondamentali
Per ricevere informazioni importanti sulle modifiche alla tua organizzazione o ai prodottiGoogle Cloud , devi fornire i contatti essenziali quando utilizzi la federazione delle identità della forza lavoro. Gli utenti di Cloud Identity possono essere contattati tramite il loro indirizzo email di Cloud Identity, mentre gli utenti della federazione delle identità per la forza lavoro vengono contattati utilizzando i contatti essenziali.
Quando utilizzi la console Google Cloud per creare o gestire i pool di identità della forza lavoro, viene visualizzato un banner che ti chiede di configurare un contatto fondamentale con le categorie Legale e Sospensione. In alternativa, definisci un contatto nella categoria Tutti se non hai contatti separati. Fornire i contatti rimuove il banner.
Passaggi successivi
- Rivedi i pattern di architettura per la federazione delle identità.
- Consulta le best practice per l'utilizzo della federazione delle identità per la forza lavoro.
- Per scoprire come configurare la federazione delle identità per la forza lavoro, consulta Configurazione della federazione delle identità per la forza lavoro. Per istruzioni specifiche per il provider di identità, vedi quanto segue:
- Ottenere token di breve durata per la federazione delle identità della forza lavoro
- Gestisci i provider dei pool di forza lavoro
- Eliminare gli utenti della federazione delle identità per la forza lavoro e i relativi dati
- Revocare le sessioni utente della federazione delle identità per la forza lavoro
- Visualizzare i log di controllo della federazione delle identità della forza lavoro
- Visualizzare i prodotti che supportano la federazione delle identità della forza lavoro
- Configurare l'accesso degli utenti alla console (federato)