Informazioni sulla federazione di Workload Identity del parco risorse

Questa pagina descrive la federazione delle identità dei workload del parco risorse, un meccanismo per autenticare le richieste dai workload del parco risorse alle API Google Cloud . In questa pagina, scopri di più sull'identità dei carichi di lavoro, sul funzionamento della federazione di Workload Identity delle risorse e sulle best practice per la gestione su larga scala.

Questa pagina è destinata 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, consulta Ruoli utente e attività comuni di GKE. Google Cloud

Prima di leggere questa pagina, assicurati di avere familiarità con i seguenti concetti:

Informazioni sulle identità federate dei workload in Google Cloud

Workload Identity Federation è una Google Cloud funzionalità che consente ai carichi di lavoro nei tuoi cluster di autenticarsi su Google Cloud senza richiedere di scaricare, ruotare manualmente e gestire in generale le credenziali. I workload vengono autenticati 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 di identità dei carichi di lavoro gestito da Google a livello di progetto da cui le applicazioni in esecuzione nei cluster GKE ottengono 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 i cluster si trovino in progetti diversi o al di fuori di Google Cloud. Con la federazione delle identità per i carichi di lavoro del parco risorse, i cluster registrati che hanno abilitato la federazione delle identità per i carichi di lavoro nella loro appartenenza al parco risorse ottengono identità utilizzando un pool di identità per i carichi di lavoro gestito da Google a livello di parco risorse. Questo pool condiviso ti consente di configurare l'autenticazione per le API e per altri servizi in tutto il parco risorse, anche in più progetti. Google Cloud

La federazione delle identità per i carichi di lavoro del parco risorse può essere utilizzata anche dall'agente Connect su alcuni tipi di cluster per l'autenticazione a Google Cloud nell'ambito dell'appartenenza al parco risorse ed è necessaria per utilizzare alcune funzionalità di GKE 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 abiliti Workload Identity Federation for GKE sui tuoi cluster, il progetto cluster riceve un pool di identità per i carichi di lavoro gestito da Google con un nome fisso e specifico del progetto. Le applicazioni nei tuoi cluster ottengono identità dal pool di identità dei carichi di lavoro gestito da Google per autenticare le chiamate API. Google Cloud Il pool di identità dei carichi 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 host del parco risorse è anche il pool di identità per i carichi di lavoro per tutti i cluster che registri nel parco risorse, indipendentemente dal fatto che questi cluster si trovino in altri progetti o al di fuori di Google Cloud. Ogni cluster nel 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 ambiti del team, puoi configurare facoltativamente un pool Workload Identity IAM autogestito da utilizzare nei cluster in aggiunta al pool gestito da Google. Questo pool autogestito fornisce un controllo più esplicito su quali carichi di lavoro ottengono identità specifiche.

Ogni applicazione nel tuo parco risorse riceve un'identità federata distinta dal pool di identità del workload del parco risorse, che l'applicazione può utilizzare per l'autenticazione aGoogle Cloud e ad altri servizi che sviluppi. Le applicazioni ricevono un identificatore principale che IAM può riconoscere. 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 selezionato nel campo SELETTORE.
  • FLEET_PROJECT_NUMBER: il numero di progetto del progetto host del parco progetti.

  • WORKLOAD_IDENTITY_POOL_NAME: il pool di identità del workload per il tuo parco risorse. Questo valore dipende dal pool di identità del carico di lavoro che hai 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 autogestito (anteprima): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, dove POOL_HOST_PROJECT_NUMBER è il numero di progetto del progetto in cui hai creato il pool di identità del workload autogestito.

  • SELECTOR: il selettore risorse. Per un elenco dei selettori supportati, consulta la sezione Identificatori delle entità supportati. Ad esempio, subject/ns/NAMESPACE/sa/SERVICEACCOUNT seleziona un ServiceAccount Kubernetes specifico in uno spazio dei nomi specifico.

L'intera flotta condivide un pool di identità del workload della flotta, in modo da poter concedere alle applicazioni ovunque nella flotta, inclusi altri progetti o cloud, l'accesso alle stesse risorse senza dover gestire l'accesso per ogni cluster.

Informazioni sull'identità

Come altre funzionalità abilitate per il parco risorse, la federazione delle identità dei carichi di lavoro 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 vengono trattati come la stessa cosa. Per saperne di più sul principio generale di uguaglianza nei parchi risorse, consulta Uguaglianza.

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

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

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

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

Per impostazione predefinita, il tuo parco risorse utilizza il pool di identità del carico di lavoro gestito da Google del progetto host del parco risorse per fornire identità ai carichi di lavoro nel parco risorse. Tutti i cluster nel progetto host del parco risorse, inclusi i cluster autonomi non registrati nel parco risorse, utilizzano questo pool di identità del workload. 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 non intenzionale.

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 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 consentono di definire spazi dei nomi Kubernetes all'interno di ambiti di team specifici, in modo che determinati team possano eseguire carichi di lavoro solo negli spazi dei nomi nel loro ambito del team. Per maggiori dettagli, consulta Panoramica della gestione del team del parco risorse.

Se utilizzi gli ambiti del team, puoi mitigare le complessità dell'identità nelle fleet multi-tenant configurando il tuo pool di identità dei carichi di lavoro per cluster specifici della tua fleet da utilizzare al posto del pool di identità dei carichi di lavoro gestito da Google. Di conseguenza, gli identificatori delle entità per questi carichi di lavoro sono esplicitamente diversi dagli identificatori delle entità per i cluster autonomi nel progetto. Questa identità esplicita offre agli amministratori un maggiore controllo sui limiti entro i quali si applica l'identità.

Il modello di identità identica nel tuo parco risorse cambia come segue, a seconda che utilizzi solo il pool di identità del workload gestito da Google o configuri un pool di identità del workload autogestito:

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

  • Identità esplicita (anteprima): configuri un pool di identità del workload autogestito per gli ambiti del team nel parco risorse. Il pool autogestito fornisce identità ai workload solo se configuri un cluster per utilizzare il pool autogestito per uno spazio dei nomi del parco risorse specifico. I workload eseguiti in altri cluster e spazi dei nomi 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à del workload gestito da Google se ogni cluster ha un livello di attendibilità simile in cui le stesse entità distribuiscono le stesse applicazioni. Ad esempio, un parco risorse specifico per il team con un cluster in ogni regione che esegue il deployment di un'applicazione replicata in ogni cluster.

Ti consigliamo di configurare un pool di identità del workload autogestito 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 i team frontend hanno cluster nello stesso parco risorse. Un pool di identità del carico di lavoro autogestito ti aiuta a separare le concessioni di accesso per ogni team in base allo spazio dei nomi del parco risorse. 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à dei carichi 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 autogestito per il parco assicura che le concessioni di accesso sul pool autogestito non concedano inavvertitamente l'accesso ai cluster standalone.
  • Best practice per gli ambiti del team: utilizzi già le funzionalità di gestione dei 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à del workload autogestito consente di concedere l'accesso ai workload in uno spazio dei nomi del parco specifico in un ambito del team senza concedere l'accesso ad altri ambiti del team che eseguono workload negli stessi cluster.

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

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

Flusso delle credenziali

Per consentire alle applicazioni in uno spazio dei nomi specifico di autenticarsi utilizzando la federazione delle identità per il parco risorse, esegui le seguenti operazioni:

  1. Esegui il deployment di un ConfigMap in questo spazio dei nomi con le seguenti informazioni:

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

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

  2. Crea una policy di autorizzazione IAM che conceda l'accesso a risorseGoogle Cloud specifiche all'identificatore dell'entità nell'entità nei tuoi cluster, ad esempio un ServiceAccount nello spazio dei nomi.

  3. Assicurati che il tuo workload 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 ServiceAccount 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 container che fa riferimento al volume proiettato.

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

  1. Le librerie di autenticazione Google Cloud utilizzano le credenziali predefinite dell'applicazione (ADC) per trovare le credenziali. 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 in ConfigMap per scambiare il JWT ServiceAccount che hai montato sul pod con un token di accesso federato di breve durata dal servizio token di sicurezza che fa riferimento all'identificatore principale del carico di lavoro.
  3. ADC include il token di accesso federato con la richiesta API.
  4. La policy di autorizzazione IAM autorizza l'identificatore dell'entità a eseguire l'operazione richiesta sulla risorsa Google Cloud .

Identificatori principal supportati per la federazione delle identità per i workload del parco risorse

La seguente tabella descrive i selettori che puoi utilizzare nei criteri di autorizzazione IAM per fare riferimento alle entità nei fleet:

Tipo di identificatore entità Sintassi
Tutti i pod che utilizzano un ServiceAccount Kubernetes specifico Seleziona ServiceAccount 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 ServiceAccount 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: il tuo ID progetto Fleet.
  • SERVICEACCOUNT_UID: l'UID dell'oggetto ServiceAccount nel server API.

Passaggi successivi