Federazione delle identità per la forza lavoro

Questo documento descrive i concetti chiave della federazione delle identità della forza lavoro.

Che cos'è la federazione delle identità per la forza lavoro?

La federazione delle identità per la 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 collaboratori, 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 con le identità 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 il Single Sign-On basato sugli attributi e senza sincronizzazione.

Dopo l'autenticazione dell'utente, le informazioni ricevute dal provider di identità 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 ti 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 employees o partners.
  • Concedi l'accesso IAM a un intero pool o a un sottoinsieme.
  • 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, inclusi il mapping 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 pool.

Puoi creare più pool. Per un esempio che descrive uno di questi approcci, vedi Esempio: più pool di identità della forza lavoro.

I pool vengono configurati a Google Cloud livello di organizzazione. 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 visualizzare il pool. Quando configuri per la prima volta la federazione delle identità per la forza lavoro per la tua organizzazione, fornisci un nome per il pool. Nelle policy di autorizzazione IAM, fai riferimento al pool in base al nome. Per questo motivo, ti consigliamo di denominare il pool in modo 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 IdP.

La federazione delle identità per la forza lavoro segue la specifica di scambio di token OAuth 2.0 (RFC 8693). Fornisci una credenziale del tuo provider di identità 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à della forza lavoro supporta sia il flusso di 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.

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 rivendicazioni. 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 norme di autorizzazione IAM.

La dimensione massima per i mapping degli attributi è 16 kB. Se le dimensioni delle mappature 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 Cloud Audit Logs registrano i contenuti di questo campo come entità. 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 per google.groups sono 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ù ridotto di gruppi nell'asserzione e mappare solo i gruppi utilizzati per federare l'utente aGoogle Cloud.

    • Se utilizzi questo attributo per concedere l'accesso in IAM, ogni membro dei gruppi mappati riceve 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 Google Cloud console. Questo attributo non può essere utilizzato nelle policy 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 che la foto sia di 400 x 400 pixel. Se 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 né nei criteri di autorizzazione IAM né nella condizione dell'attributo.

  • google.posix_username (Facoltativo): una stringa del nome utente univoca conforme a POSIX utilizzata per:

    Questo attributo non può essere utilizzato nelle norme 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 norme 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.email nella mappatura degli attributi.

    Esempi di prodotti Google Cloud 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 un criterio 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à con l'attributo costcenterimpostato su 1234 hanno 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_description potrebbe cambiare per molti motivi (ad esempio per migliorarne la leggibilità). In alternativa, puoi utilizzare attribute.role. Le modifiche a quest'ultima 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 split divide una stringa in base al valore del separatore fornito. Ad esempio, per estrarre l'attributo username da un attributo indirizzo email dividendo il relativo valore in corrispondenza di @ e utilizzando la prima stringa, utilizza il seguente mapping degli attributi: 

    attribute.username=assertion.email.split("@")[0]

  • La funzione join unisce un elenco di stringhe in base al valore del separatore fornito. Ad esempio, per compilare l'attributo personalizzato department 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 consentono di impostare vincoli sugli attributi 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. Un altro esempio: potresti voler consentire l'accesso al team contabilità, ma non al team tecnico.
  • Le condizioni degli attributi ti consentono di impedire l'utilizzo con Google Clouddi credenziali destinate a un'altra piattaforma e viceversa. In questo modo si evita il problema del delegato confuso.

Utilizzare le condizioni degli attributi durante la federazione con GitHub o altri provider di identità 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 provider di identità (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 dell'emittente del token.

I provider di identità multi-tenant, come GitHub e Terraform Cloud, utilizzano un unico URL dell'emittente in tutti i loro tenant. Per questi provider, l'URL dell'emittente identifica tutti di GitHub o Terraform Cloud, non un'organizzazione GitHub o Terraform Cloud specifica.

Quando utilizzi questi provider di identità, non è sufficiente consentire a Workforce Identity Federation di controllare l'URL dell'emittente di un token per assicurarsi che provenga da un'origine attendibile e che le sue attestazioni siano attendibili. Se il tuo IdP multitenant ha un singolo URL emittente, ti consigliamo di utilizzare le condizioni degli attributi per assicurarti che l'accesso sia limitato al tenant corretto.

Rappresentare gli utenti del pool di forza lavoro nelle policy IAM

La seguente tabella mostra gli identificatori delle entità utilizzati per concedere ruoli a un singolo utente, a un gruppo di utenti, a utenti con una determinata rivendicazione o a tutti gli utenti di un pool di forza lavoro.

Identità Formato dell'identificatore
Singola 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 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à per la forza lavoro principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

Per un elenco completo degli identificatori delle entità, consulta Identificatori delle entità.

Audit logging dettagliato

Il logging di controllo dettagliato è una funzionalità della federazione delle identità della forza lavoro che registra gli attributi ricevuti dal tuo 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 di controllo dettagliata, consulta Errori generali di mappatura degli attributi.

Chiavi web JSON

Il fornitore del pool della forza lavoro può accedere alle JSON Web Key (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 l'emittente non è accessibile pubblicamente, puoi caricare manualmente le JWK quando crei o aggiorni il provider OIDC.

Limitare l'accesso tra organizzazioni

Le entità dei 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 utilizzare un service account all'interno dell'organizzazione, questo vincolo può essere aggirato poiché i service account non sono soggetti alle stesse restrizioni.

Progetto utente dei pool di forza lavoro

La maggior parte delle API Google Cloud addebita l'utilizzo della fatturazione e delle quote al progetto che contiene la risorsa a cui accede la richiesta API. Queste API sono chiamate API basate sulle risorse. Alcune Google Cloud API vengono addebitate al progetto associato al client; queste sono chiamate API basate sul client. Il progetto utilizzato per la fatturazione e la quota è chiamato 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 viene utilizzato per identificare la tua applicazione per le API di Google che chiama. Il progetto utente dei pool di forza lavoro viene utilizzato anche come progetto di quota predefinito per le API basate su client, a meno che tu non utilizzi gcloud CLI per avviare la richiesta API. Devi disporre dell'autorizzazione serviceusage.services.use, inclusa nel ruolo Consumer di Service Usage (roles/serviceusage.serviceUsageConsumer), per il progetto che specifichi.

Per ulteriori informazioni sul progetto di quota, sulle API basate sulle risorse e sulle API basate sui 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 possono 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 di esempio 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à:

  1. Crea un'identità come partner-organization-admin@example.com per l'amministratore dell'organizzazione di esempio del partner nel provider di identità dell'organizzazione di esempio dell'azienda, che è già configurato nel pool denominato enterprise-example-organization-employees.

  2. Crea un nuovo pool di forza lavoro denominato example-organization-partner.

  3. 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"
      ]
    }
  ]
}

  4. Assegna i ruoli per il pool example-organization-partner alle risorse a cui deve accedere nell'organizzazione Enterprise Example Organization.

L'amministratore dell'organizzazione di esempio del partner ora può configurare il pool example-organization-partner per connettersi al proprio IdP. In questo modo, possono consentire ai dipendenti dell'organizzazione partner di esempio di accedere con le credenziali del provider di identità dell'organizzazione partner di esempio. 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'azienda.

Gestione degli accessi semplificata

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 utenti ragionevolmente piatta. Una soluzione migliore per evitare errori di configurazione delle policy IAM e limitare la crescita dei gruppi è utilizzare più pool per creare una separazione più ampia degli utenti di unità organizzative e unità aziendali diverse, nonché delle organizzazioni partner. Puoi quindi fare riferimento a questi pool e gruppi contenuti al loro interno per definire i criteri IAM (vedi gli esempi nel passaggio Configurazione di IAM).

Limitazioni dei Controlli di servizio VPC

Le funzionalità amministrative della federazione delle identità della forza lavoro, incluse le API di configurazione del pool della forza lavoro e le API del servizio token di sicurezza, non supportano i Controlli di servizio VPC. Tuttavia,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 dei criteri di Controlli di servizio VPC. Google Cloud Inoltre, puoi utilizzare identità di terze parti come utenti del pool di forza lavoro e identità del carico di lavoro nelle regole di ingresso o di uscita di Controlli di servizio VPC.

Federazione delle identità per la forza lavoro e Contatti essenziali

Per ricevere informazioni importanti sulle modifiche alla tua organizzazione o ai prodottiGoogle Cloud , devi fornire i contatti essenziali quando utilizzi Workforce Identity Federation. 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, vedrai un banner che ti chiede di configurare un contatto fondamentale con le categorie Legale e Sospensione. In alternativa, puoi definire un contatto nella categoria Tutti se non hai contatti separati. Se fornisci i contatti, il banner verrà rimosso.

Passaggi successivi