Questo documento descrive i concetti chiave di Workforce Identity Federation.
Che cos'è la federazione delle identità per la forza lavoro?
La federazione delle identità della forza lavoro ti consente di utilizzare un provider di identità (IdP) esterno per autenticare e autorizzare una forza lavoro, ovvero un gruppo di utenti, come dipendenti, partner e appaltatori, utilizzando IAM, in modo che gli utenti possano accedere ai servizi Google Cloud. Con la federazione delle identità della forza lavoro non è necessario sincronizzare le identità utente dal tuo IdP esistente alle identità di Google Cloud, come faresti con Google Cloud Directory Sync (GCDS) di Cloud Identity. La federazione delle identità per la forza lavoro estende le funzionalità di identità di Google Cloud per supportare l'accesso singolo senza sincronizzazione basato sugli attributi.
Dopo l'autenticazione dell'utente, le informazioni ricevute dall'IdP vengono utilizzate per determinare l'ambito di accesso alle risorse Google Cloud.
Puoi utilizzare la federazione delle identità della 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.
Pool di identità della forza lavoro
I pool di identità della forza lavoro consentono di gestire gruppi di forza lavoro identità e il loro accesso alle risorse Google Cloud.
I pool ti consentono di:
- Identità utente di gruppo; ad esempio,
employees
opartners
- Concedi l'accesso IAM a un intero pool o a un sottoinsieme dello stesso.
- Federa le identità da uno o più provider di identità.
- Definisci i criteri per un gruppo di utenti che richiedono autorizzazioni di accesso simili.
- Specifica le informazioni di configurazione specifiche dell'IdP, inclusa la mappatura degli attributi. e le condizioni degli attributi.
- Attiva l'accesso a Google Cloud CLI e all'API per le identità di terze parti.
- Registra l'accesso degli utenti all'interno di un pool in Cloud Audit Logs, insieme all'ID pool.
Puoi creare più pool. Per un esempio che descrive uno di questi approcci, consulta Esempio: più pool di identità della forza lavoro.
I pool sono configurati a livello di organizzazione Google Cloud. Per questo motivo, i pool sono disponibili in tutti i progetti e le cartelle dell'organizzazione, a condizione che tu disponga delle autorizzazioni IAM appropriate per visualizzarli. Quando configuri per la prima volta la federazione delle identità per la forza lavoro per organizzazione, fornisci un nome per il pool. In IAM, consenti di controllo, fai riferimento al pool con il nome. Per questo motivo, ti consigliamo di assegnare al pool un nome che descriva chiaramente le identità che contiene.
Provider di pool di identità per la 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 provider di identità.
La federazione delle identità per la forza lavoro è conforme alla specifica per lo scambio di token OAuth 2.0 (RFC 8693). Fornisci una credenziale del tuo provider di identità esterno al Security Token Service, che verifica l'identità nella credenziale e restituisce in cambio un token di accesso Google Cloud di breve durata.
Tipi di flusso OIDC
Per i provider OIDC, Workforce Identity Federation supporta sia il flusso di codice di autorizzazione che 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. Come come risultato, le transazioni del flusso di codice possono recuperare token di qualsiasi dimensione, più dichiarazioni da utilizzare per la mappatura e la condizione degli attributi. Nel flusso implicito, invece, il token ID viene restituito dall'IDP al browser. I token sono soggetti a limiti di dimensioni dei singoli URL del browser.
Console della federazione delle identità per la forza lavoro di Google Cloud
Gli utenti di un pool di identità della forza lavoro possono accedere alla console della federazione delle identità della forza lavoro di Google Cloud, nota anche come console (federata). La console fornisce a questi utenti l'accesso all'interfaccia utente dei prodotti Google Cloud che supportano la federazione delle identità della forza lavoro.
Mappature attributi
L'IdP fornisce attributi, chiamati da alcuni IdP claim. Attributi contenere informazioni sui tuoi utenti. Puoi mappare questi attributi per utilizzarli da Google Cloud utilizzando il 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 possano essere utilizzati specifici prodotti Google Cloud; Ad esempio, in IAM criteri.
La dimensione massima per le mappature degli attributi è 4 kB.
Gli attributi sono i seguenti:
google.subject
(obbligatorio): un identificatore univoco per l'utente che esegue l'autenticazione. Spesso è l'affermazione sull'oggetto del JWT, perché i log Cloud Audit registrano i contenuti di questo campo come principale. Tu puoi utilizzare questo campo per configurare IAM per l'autorizzazione prendono le loro decisioni. Ti consigliamo di non utilizzare un valore mutabile perché, se lo cambi nella directory utente dell'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 usare questo campo per configurare IAM per le decisioni sull'autorizzazione. Le limitazioni pergoogle.groups
sono le seguenti:Ti consigliamo di limitare il nome del gruppo a 100 caratteri.
Se un utente è associato a più di 100 gruppi, definisci un valore più piccolo un insieme di gruppi e includerli solo nelle asserzioni usate per federare l'utente in Google Cloud. Se un utente appartiene a più di 100 gruppi, autenticazione non riuscita.
Se utilizzi questo attributo per concedere l'accesso in IAM, l'accesso viene concesso a ogni membro dei gruppi mappati. Pertanto, consigliamo di garantire che solo gli utenti autorizzati nell'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é nell'attributo .La lunghezza massima è di 100 byte.
google.profile_photo
(facoltativo): un URL della foto in miniatura dell'utente. Le dimensioni consigliate sono 400 x 400 pixel. Quando questo attributo è impostato, è 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 nei criteri di IAM per consentire o nella condizione dell'attributo.google.posix_username
(facoltativo): una stringa di nome utente conforme a POSIX univoca utilizzata per quanto segue:Questo attributo non può essere utilizzato nei criteri di autorizzazione IAM o nella condizione dell'attributo. La lunghezza massima è di 32 caratteri.
attribute.KEY
(Facoltativo): un attributo definito dal cliente presente nel token IdP di un utente. Puoi utilizzare questi attributi personalizzati per definire la tua strategia di autorizzazione in un criterio di autorizzazione IAM. Ad esempio, puoi scegliere di definire un attributo come il centro di costo dell'utente:attribute.costcenter = "1234"
. Questo attributo potrebbe quindi può essere utilizzata nelle condizioni IAM per concedere l'accesso solo agli utenti in centro di costo.Puoi configurare un massimo di 50 regole di mappatura degli attributi personalizzati. La la dimensione massima di ciascuna regola è 2048 caratteri.
Anche se non esistono restrizioni sugli attributi che puoi mappare qui, Consigliamo vivamente di scegliere attributi con valori stabili. Per Ad esempio, un attributo come
attribute.job_description
potrebbe cambiare ad esempio migliorandone la leggibilità. In alternativa, valuta l'utilizzoattribute.role
. Le modifiche a quest'ultimo indicano un cambio di responsabilità ed essere conformi alle modifiche dell'accesso concesso all'utente.
Puoi trasformare i valori degli attributi utilizzando le funzioni CEL standard. Puoi anche utilizzare le seguenti funzioni personalizzate:
La funzione
split
suddivide una stringa in base al valore del separatore fornito. Ad esempio, per estrarre l'attributousername
da un attributo di indirizzo email suddividendone il valore in corrispondenza di@
e utilizzando la prima stringa, usa la seguente mappatura degli attributi:attribute.username=assertion.email.split("@")[0]
Funzione
join
unisce un elenco di stringhe sul valore separatore fornito. Ad esempio, per compilare l'attributo personalizzatodepartment
concatenando 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 ti consentono di impostare i vincoli sugli attributi riguardanti l'identità accettati da Google Cloud.
I vantaggi dell'utilizzo delle condizioni degli attributi includono quanto segue:
- Puoi utilizzare le condizioni degli attributi per consentire solo a un sottoinsieme di identità esterne di eseguire l'autenticazione nel tuo progetto Google Cloud. Ad esempio: potresti voler consentire solo le identità che si trovano in un per l'accesso, soprattutto se usi un IdP pubblico. Per un altro esempio, potresti consentire al tuo team di contabilità di firmare ma non nel tuo team tecnico.
- Le condizioni degli attributi consentono di impedire le credenziali destinate all'utilizzo con l'uso di un'altra piattaforma con Google Cloud e viceversa. Ciò aiuta a evitare il problema confuso con il vicepresidente.
Utilizzare le condizioni degli attributi durante la federazione con GitHub o altri provider di identità multi-tenant
La federazione delle identità per la forza lavoro non gestisce una directory di account utente,
implementa invece le identità basate sulle attestazioni. Di conseguenza, quando due token vengono emessi dallo stesso provider di identità (IdP) e i relativi claim mappano allo stesso valore google.subject
, si presume che i due token identifichino lo stesso utente. A
l'IdP ha emesso un token, la federazione delle identità per la forza lavoro controlla e
consente di verificare l'URL dell'emittente del token.
Gli IdP multi-tenant, come GitHub e Terraform Cloud, utilizzano un URL dell'emittente singolo a tutti i loro inquilini. 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 la forza lavoro controlla l'URL emittente di un token per verificare che proviene da una fonte attendibile e che le sue dichiarazioni siano attendibili. Se le tue che l'IdP multi-tenant ha un singolo URL emittente, ti consigliamo di usare delle condizioni degli attributi per garantire che l'accesso sia limitato al tenant corretto.
Rappresenta gli utenti del pool di forza lavoro nei criteri IAM
La tabella seguente mostra gli identificatori principali che utilizzi per concedere i ruoli a un singolo utente, a un gruppo di utenti, a utenti che presentano una determinata rivendicazione o a tutti gli utenti di un pool di risorse umane.
Identità | Formato dell'identificatore |
---|---|
Un'unica identità in un pool di identità per la 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 dell'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/*
|
Chiavi web JSON
Il fornitore del pool della forza lavoro può accedere alle JSON Web Key (JWK) fornite dall'IdP nel campo jwks_uri
del documento /.well-known/openid-configuration
. Se il provider OIDC non
fornire queste informazioni o che l'emittente non sia accessibile pubblicamente,
caricare manualmente i JWK quando crei o aggiorni il provider OIDC.
Limita 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 un'entità viene ha ricevuto l'autorizzazione a simulare l'identità di un account di servizio all'interno dell'organizzazione, questo vincolo può essere ignorato come account di servizio non hanno le stesse restrizioni.
Progetto utente dei pool di forza lavoro
La maggior parte delle API Google Cloud addebita fatturazione e utilizzo della quota per il progetto che contiene la risorsa a cui accede la tua richiesta API. Queste API prendono il nome API basate sulle risorse. Alcune API Google Cloud vengono addebitate al progetto associato al client; si tratta delle API basate su client. Il progetto utilizzato ai fini della fatturazione e delle quote è chiamato progetto quota.
Quando crei un file di configurazione della federazione delle identità della forza lavoro,
specifica un progetto utente per i pool di forza lavoro. Questo progetto viene utilizzato per identificare
alle API di Google che chiama. Il progetto utente dei pool di forza lavoro viene utilizzato anche come progetto quota predefinito per le API basate su client, a meno che non utilizzi gcloud CLI per avviare la richiesta API. Devi disporre dell'autorizzazione serviceusage.services.use
, inclusa nel ruolo Consumatore (roles/serviceusage.serviceUsageConsumer
) di utilizzo del servizio, per il progetto specificato.
Per ulteriori informazioni sul progetto quota, sulle API basate su risorse e sulle API basate su client, consulta la Panoramica del progetto 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 possono creare pool separati per le diverse divisioni della loro organizzazione. I pool consentono la gestione distribuita, in cui diversi gruppi può gestire in modo indipendente il proprio pool specifico, dove i ruoli vengono concessi solo di identità nel pool.
Ad esempio, supponiamo che un'azienda chiamata Enterprise Example Organization stipuli un contratto con un'altra azienda chiamata Partner Example Organization Inc per fornire servizi DevOps di Google Kubernetes Engine (GKE). Per un'organizzazione di esempio partner
che forniscano i servizi, devono poter accedere
Google Kubernetes Engine (GKE) e altre risorse Google Cloud in Enterprise
Esempio di organizzazione dell'organizzazione. Organizzazione già Enterprise di esempio
ha un pool di identità della forza lavoro denominato enterprise-example-organization-employees
.
Consentire all'organizzazione Partner Example di gestire l'accesso a Enterprise Example risorse dell'organizzazione, Enterprise Example Organization crea un pool di forza lavoro per gli utenti dell'organizzazione Partner di esempio, in modo che Partner L'organizzazione di esempio può gestirlo. L'organizzazione Enterprise Example fornisce il pool di risorse umane a un amministratore dell'organizzazione Partner Example. Contatto speciale L'amministratore di un'organizzazione di esempio utilizza il proprio IdP per concedere l'accesso forza lavoro.
A questo scopo, l'amministratore dell'organizzazione Enterprise Example esegue le seguenti attività:
Crea un'identità come
partner-organization-admin@example.com
per l'amministratore dell'organizzazione Partner Example nell'organizzazione Enterprise Example, che è già configurata nel pool chiamatoenterprise-example-organization-employees
.Crea un nuovo pool di risorse umane denominato
example-organization-partner
.Crea il seguente criterio 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 a
example-organization-partner
pool sulle risorse che devono accedere all'organizzazione dell'organizzazione Enterprise Example.
L'amministratore dell'organizzazione Partner di esempio ora può configurare
Pool example-organization-partner
per la connessione con il relativo IdP. In seguito, può consentire al personale dell'organizzazione Partner Example di accedere con le credenziali dell'IdP dell'organizzazione Partner Example. Dopo l'accesso, il partner Organizzazione di esempio
gli utenti della forza lavoro possono accedere alle risorse Google Cloud, vincolati da criteri
definite da Enterprise Example Organization.
Gestione degli accessi semplificata
Nelle grandi aziende, gli amministratori IT spesso creano gruppi di sicurezza 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 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 modo molto approfondito 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 utente ragionevolmente piatta. R soluzione migliore per prevenire la configurazione errata dei criteri IAM limitare la crescita dei gruppi consiste nell'utilizzare più pool per creare una separazione più ampia di utenti di diverse unità organizzative e unità aziendali e di partner le tue organizzazioni. Puoi quindi fare riferimento a questi pool e gruppi contenuti all'interno questi pool per definire i criteri IAM (vedi esempi nella il passaggio per la configurazione di IAM).
Limitazioni dei Controlli di servizio VPC
La federazione delle identità per la forza lavoro, le API di configurazione dei pool di personale e le API Security Token Service non supportano i Controlli di servizio VPC. Tuttavia, i prodotti Google Cloud a cui gli utenti del pool di personale possono accedere supportano Controlli di servizio VPC. Per saperne di più, consulta Prodotti supportati e limitazioni di Controlli di servizio VPC .
Workforce Identity Federation e Contatti necessari
Per ricevere informazioni importanti su cambiamenti della tua organizzazione o Per i prodotti Google Cloud, devi fornire i contatti necessari quando utilizzi Federazione delle identità per la forza lavoro. Gli utenti di Cloud Identity possono essere contattati tramite l'indirizzo email di Cloud Identity, ma gli utenti della federazione delle identità per la forza lavoro vengono contattati utilizzando Contatti necessari.
Quando utilizzi la console Google Cloud per creare o gestire i pool di identità della forza lavoro, vedrai un banner che ti chiede di configurare un contatto essenziale con Categoria Legale e Sospensione. In alternativa, puoi definire un contatto nella categoria Tutti se non hai contatti separati. La fornitura del contatti rimuoverà il banner.
Passaggi successivi
- Per scoprire come configurare la federazione delle identità per la forza lavoro, consulta Configurare la federazione delle identità per la forza lavoro. Per le istruzioni specifiche per l'IdP, vedi:
- Ottenere token di breve durata per la federazione delle identità della forza lavoro
- Gestire i provider dei pool di forza lavoro
- Eliminare gli utenti di Workforce Identity Federation e i relativi dati
- Visualizza gli audit log della federazione delle identità per la forza lavoro
- Visualizzare i prodotti che supportano la federazione delle identità della forza lavoro
- Configura l'accesso utente alla console (in federazione)