Informazioni sulla federazione di Workload Identity del parco risorse

Questa pagina descrive la federazione di Workload Identity delle risorse, un meccanismo per autenticare le richieste dai carichi di lavoro delle risorse alle API. Google Cloud In questa pagina scoprirai l'identità uguale per i carichi di lavoro, come funziona la federazione di Workload Identity per i parchi risorse e le best practice per gestirla su larga scala.

Questa pagina è rivolta agli amministratori e agli operatori della piattaforma e agli ingegneri della sicurezza che vogliono gestire in modo più efficiente l'autorizzazione dei workload su larga scala. Per scoprire di più sui ruoli utente e sulle attività di esempio a cui facciamo riferimento nella documentazione Google Cloud, consulta Ruoli utente e attività comuni di GKE Enterprise.

Prima di leggere questa pagina, assicurati di conoscere i seguenti concetti:

Informazioni sulle identità per i workload federate in Google Cloud

La federazione delle identità per i carichi di lavoro è una Google Cloud funzionalità che consente ai carichi di lavoro nei tuoi cluster di autenticarsi in Google Cloud senza richiedere di scaricare, ruotare manualmente e gestire in generale le credenziali. I carichi di lavoro si autenticano invece utilizzando token di breve durata generati da Google Cloud.

Workload Identity Federation for GKE è un'implementazione specifica di GKE di Workload Identity Federation che fornisce un pool Workload Identity gestito da Google a livello di progetto da cui le applicazioni in esecuzione nei cluster GKE ricevono le identità. La federazione delle identità per i carichi di lavoro del parco risorse estende la federazione delle identità per i carichi di lavoro per GKE a tutti i cluster membri del parco risorse, indipendentemente dal fatto che si trovino in progetti diversi o al di fuori di Google Cloud. Con la federazione di Workload Identity del parco risorse, i cluster registrati che hanno attivato la federazione di Workload Identity per l'appartenenza al parco risorse ottengono le identità utilizzando un pool di identità di carico di lavoro gestito da Google a livello di parco risorse. Questo pool condiviso ti consente di configurare l'autenticazione alle Google Cloud API e ad altri servizi nell'intero parco risorse, anche in più progetti.

La federazione delle identità per i carichi di lavoro del parco risorse può essere utilizzata anche dall'agente di connessione su alcuni tipi di cluster per l'autenticazione Google Cloud nell'ambito dell'appartenenza al parco risorse ed è obbligatoria per utilizzare alcune funzionalità di GKE Enterprise che funzionano in più progetti, come Cloud Service Mesh.

Informazioni sui pool di identità del workload

Un pool di identità del workload è un'entità che gestisce centralmente le identità per le tue applicazioni. Quando attivi la federazione delle identità per i carichi di lavoro per GKE sui tuoi cluster, il progetto del cluster riceve un pool di identità per i carichi di lavoro gestito da Google con un nome fisso specifico per il progetto. Le applicazioni nei tuoi cluster ricevono le identità dal pool di identità per i carichi di lavoro gestito da Google per autenticare le chiamate Google Cloud API. Il pool di identità di carico di lavoro gestito da Google ha la sintassi PROJECT_ID.svc.id.goog, dove PROJECT_ID è l'ID progetto del cluster.

Con la federazione delle identità per i carichi di lavoro del parco risorse, il pool di identità per i carichi di lavoro gestito da Google del progetto di hosting del parco risorse è anche il pool di identità per i carichi di lavoro di tutti i cluster registrati al parco risorse, indipendentemente dal fatto che si trovino in altri progetti o al di fuori di Google Cloud. Ogni cluster del parco risorse utilizza il pool di identità del workload FLEET_HOST_PROJECT_ID.svc.id.goog, dove FLEET_HOST_PROJECT_ID è l'ID progetto del progetto host del parco risorse.

Se utilizzi gli ambiti di gruppo, se vuoi puoi configurare un pool di identità di workload IAM autogestite per i cluster da utilizzare oltre al pool gestito da Google. Questo pool autogestito offre un controllo più esplicito sui carichi di lavoro che ricevono identità specifiche.

Ogni applicazione del tuo parco risorse riceve un'identità federata distinta dal pool di identità di carico di lavoro del parco risorse che l'applicazione può utilizzare per autenticarsiGoogle Cloud e per altri servizi che sviluppi. Le applicazioni ricevono un identificatore principale che può essere riconosciuto da IAM. Questo identificatore utilizza la seguente sintassi:

PREFIX://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/SELECTOR

Questa sintassi ha i seguenti campi:

  • PREFIX: principal o principalSet, a seconda del tipo di risorsa Kubernetes selezionata nel campo SELETTORE.
  • FLEET_PROJECT_NUMBER: il numero del progetto del progetto host del parco risorse.

  • WORKLOAD_IDENTITY_POOL_NAME: il pool di identità del workload per il tuo parco risorse. Questo valore dipende dal pool di identità di carico di lavoro configurato in ogni cluster, come segue:

    • Pool di identità dei carichi di lavoro gestito da Google: FLEET_HOST_PROJECT_ID.svc.id.goog

    • Pool di identità del workload autogestite (anteprima): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, dove POOL_HOST_PROJECT_NUMBER è il numero del progetto in cui hai creato il pool di identità del workload autogestito.

  • SELECTOR: il selettore delle risorse. Per un elenco dei selezionatori supportati, consulta la sezione Identificatori principali supportati. Ad esempio, subject/ns/NAMESPACE/sa/SERVICEACCOUNT seleziona un account di servizio Kubernetes specifico in uno spazio dei nomi specifico.

L'intero parco risorse condivide un pool di identità di carico di lavoro del parco risorse, in modo da poter assegnare alle applicazioni in qualsiasi punto del parco risorse, inclusi altri progetti o cloud, l'accesso alle stesse risorse senza dover gestire questo accesso per ogni cluster.

Informazioni sull'identità uguale

Come altre funzionalità abilitate per il parco risorse, la federazione Workload Identity del parco risorse si basa sul principio di identicità, in cui gli oggetti Kubernetes con lo stesso nome e spazio dei nomi in cluster diversi sono considerati uguali. Per scoprire di più sul principio generale di identità nei parchi risorse, consulta Identità.

Con la federazione delle identità per i carichi di lavoro per GKE a livello di singolo progetto, l'identità uguale si applica a tutte le entità che condividono un identificatore principale in quel progetto. Tuttavia, con la federazione Workload Identity del parco risorse, questa identità uguale si applica implicitamente a tutte le entità che condividono un identificatore principale nell'intero parco risorse, indipendentemente dal progetto del cluster.

Ad esempio, considera un'applicazione con un backend di cui è stato eseguito il deployment su più cluster nello stesso parco risorse. Se concedi un ruolo a un identificatore di entità che seleziona il service account Kubernetes default nello spazio dei nomi Kubernetes backend, qualsiasi applicazione in questo spazio dei nomi che utilizza il service account ottiene lo stesso accesso.

Se il tuo parco risorse esegue solo cluster nel progetto host del parco risorse, le implicazioni dell'identità uguale sono le stesse di Workload Identity Federation per GKE. Tuttavia, se il tuo parco risorse ha cluster in esecuzione in altri progetti o al di fuori diGoogle Cloud, questa identità implicita si estende a tutti i cluster registrati nel parco risorse.

Identità uguali in ambienti multi-tenant o con attendibilità mista

Per impostazione predefinita, il parco risorse utilizza il pool di identità di carico di lavoro gestito da Google del progetto di destinazione del parco risorse per fornire identità ai carichi di lavoro del parco risorse. Tutti i cluster nel progetto host del parco risorse, inclusi i cluster autonomi non registrati al parco risorse, utilizzano questo pool di identità di carico di lavoro. In un ambiente con attendibilità mista in cui questi cluster autonomi eseguono carichi di lavoro con un modello di attendibilità diverso, questa uguaglianza implicita dell'identità potrebbe comportare un accesso involontario.

I parchi risorse ti consentono di gestire questo modello multi-tenant utilizzando gli ambiti dei team e gli spazi dei nomi del parco risorse. Gli ambiti dei team ti consentono di designare sottoinsiemi di risorse del parco risorse, come i cluster, per l'utilizzo da parte di team specifici della tua organizzazione. Gli spazi dei nomi del parco risorse ti consentono di definire spazi dei nomi Kubernetes in ambiti di team specifici, in modo che determinati team possano eseguire carichi di lavoro solo negli spazi dei nomi nel loro ambito. Per maggiori dettagli, consulta la panoramica della gestione del team del parco risorse.

Se utilizzi gli ambiti di gruppo, puoi ridurre le complessità dell'identità uguale nei parchi risorse multi-tenant configurando un pool di identità per i carichi di lavoro per cluster specifici del parco risorse da utilizzare anziché il pool di identità per i carichi di lavoro gestito da Google. Di conseguenza, gli identificatori principali di questi carichi di lavoro sono esplicitamente diversi dagli identificatori principali dei cluster autonomi nel progetto. Questa identità esplicita offre agli amministratori un maggiore controllo sui confini entro i quali si applica l'identità.

Il modello di identità uguale nel tuo parco risorse cambia come segue, a seconda che tu utilizzi solo il pool di identità dei carichi di lavoro gestito da Google o configuri un pool di identità dei carichi di lavoro autogestito:

  • Identità implicita uguale: tutti i carichi di lavoro di un parco risorse utilizzano il pool di identità di workload gestito da Google. Di conseguenza, ogni carico di lavoro che condivide lo stesso identificatore principale condivide implicitamente lo stesso accesso.

  • Identità uguali esplicite (anteprima): configuri un pool Workload Identity autogestito per gli ambiti di gruppo nel parco risorse. Il pool autogestito fornisce identità ai carichi di lavoro solo se configuri un cluster per utilizzare il pool autogestito per uno spazio dei nomi del parco risorse specifico. I carichi di lavoro eseguiti in altri spazi dei nomi e cluster Kubernetes non possono utilizzare il pool autogestito.

    Di conseguenza, l'identità dei carichi di lavoro che utilizzano il pool autogestito è diversa da quella dei carichi di lavoro che possono utilizzare solo il pool di identità dei carichi di lavoro gestito da Google.

Quando utilizzare i pool di identità per i carichi di lavoro autogestiti

Utilizza il pool di identità di carico di lavoro gestito da Google se ogni cluster ha un livello di attendibilità simile in cui le stesse entità eseguono il deployment delle stesse applicazioni. Ad esempio, un parco risorse specifico per team con un cluster in ogni regione che esegue il deployment di un'applicazione replicata in ogni cluster.

Ti consigliamo di configurare un pool Workload Identity autonomo per il tuo parco risorse in scenari come i seguenti:

  • Più livelli di attendibilità nel parco risorse: esegui cluster con più livelli di attendibilità. Ad esempio, considera uno scenario in cui i team finanziari e quelli frontend hanno cluster nello stesso parco risorse. Un pool di identità per i carichi di lavoro autogestiti ti consente di separare le concessioni di accesso per ogni team in base allo spazio dei nomi del parco. Ciò significa che anche l'amministratore del cluster frontend non può ottenere un'identità nello spazio dei nomi del parco risorse, a meno che non disponga di autorizzazioni esplicite.
  • Più livelli di attendibilità nel progetto: il progetto host del parco risorse esegue cluster autonomi che potrebbero non avere lo stesso livello di attendibilità dei cluster del parco risorse. Per impostazione predefinita, questi cluster autonomi utilizzano il pool di identità di carico di lavoro gestito da Google del progetto host del parco risorse. Anche i cluster del parco risorse utilizzano questo pool di identità del workload, indipendentemente dal progetto del cluster del parco risorse. L'impostazione di un pool di identità per i carichi di lavoro autogestiti per il parco risorse garantisce che le concessioni di accesso nel pool autogestito non consentano involontariamente l'accesso ai cluster autonomi.
  • Best practice per gli ambiti di gruppo: utilizzi già le funzionalità di gestione del team del parco risorse e vuoi implementare le best practice consigliate per concedere l'accesso ai carichi di lavoro. L'impostazione di un pool di identità di carico di lavoro autonomo ti consente di concedere accesso ai carichi di lavoro in uno spazio dei nomi del parco risorse specifico in un ambito di gruppo senza concedere questo accesso ad altri ambiti di gruppo che eseguono carichi di lavoro negli stessi cluster.

Come funziona la federazione delle identità per i workload del parco risorse

Le sezioni seguenti descrivono il funzionamento della federazione Workload Identity del parco risorse, incluso il flusso delle credenziali di autenticazione e gli identificatori principali IAM supportati.

Flusso di credenziali

Per consentire alle applicazioni in uno spazio dei nomi specifico di autenticarsi utilizzando la federazione delle identità per i carichi di lavoro del parco risorse, svolgi i seguenti passaggi:

  1. Esegui il deployment di un ConfigMap nello spazio dei nomi contenente le seguenti informazioni:

    • Il pool di identità del workload e il provider di identità per il tuo cluster.
    • Il percorso in ogni pod su cui Kubernetes monta un token ServiceAccount. Questo token è un token JWT (JSON Web Token) firmato.

    Questo ConfigMap funge da file delle credenziali predefinite dell'applicazione (ADC) per i workload.

  2. Crea un criterio di autorizzazione IAM che conceda l'accesso a risorse Google Cloud specifiche all'identificatore dell'entità nei tuoi cluster, ad esempio un account di servizio nello spazio dei nomi.

  3. Assicurati che il carico di lavoro nello spazio dei nomi abbia le seguenti configurazioni nella specifica del pod:

    • La variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS impostata sul percorso di montaggio del ConfigMap nel pod.
    • Un volume proiettato contenente il token dell'account di servizio e il ConfigMap che hai creato, montato nello stesso percorso specificato nella variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS.
    • Un punto di montaggio del volume nel contenitore che fa riferimento al volume proiettato.

Quando il carico di lavoro effettua una Google Cloud chiamata API, vengono eseguiti i seguenti passaggi:

  1. Le librerie di autenticazione Google Cloud utilizzano le Credenziali predefinite dell'applicazione (ADC) per trovare le credenziali. L'ADC controlla il percorso specificato nella variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS per cercare un token di autenticazione.
  2. La libreria di autenticazione ADC utilizza i dati nel ConfigMap per scambiare il JWT dell'account di servizio montato sul pod con un token di accesso federato di breve durata proveniente da Security Token Service che fa riferimento all'identificatore del principale del carico di lavoro.
  3. ADC include il token di accesso federato con la richiesta dell'API.
  4. Il criterio di autorizzazione IAM autorizza l'identificatore dell'entità a eseguire l'operazione richiesta sulla risorsa Google Cloud .

Identificatori principali supportati per la federazione di Workload Identity del parco risorse

La tabella seguente descrive i selettori che puoi utilizzare nei criteri IAM per consentire il riferimento a entità nei fleet:

Tipo di identificatore principale Sintassi
Tutti i pod che utilizzano un account di servizio Kubernetes specifico Seleziona l'account di servizio per nome: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Sostituisci quanto segue:

  • PROJECT_NUMBER: il numero numerico del progetto. Per ottenere il numero del progetto, consulta Identificazione dei progetti.
  • PROJECT_ID: il tuo ID progetto Google Cloud .
  • NAMESPACE: lo spazio dei nomi Kubernetes.
  • SERVICEACCOUNT: il nome del service account Kubernetes.
Seleziona l'account di servizio per UID: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Sostituisci quanto segue:

  • PROJECT_NUMBER: il numero numerico del progetto. Per ottenere il numero del progetto, consulta Identificazione dei progetti.
  • PROJECT_ID: l'ID del tuo progetto Fleet.
  • SERVICEACCOUNT_UID: l'UID dell'oggetto ServiceAccount nel server API.

Passaggi successivi