Prima di leggere questa guida, devi conoscere i concetti descritti in Eseguire l'autenticazione in API e servizi dai workload del parco risorse.
Per le best practice sull'adozione di altre funzionalità del parco risorse, consulta Pianificare le funzionalità del parco risorse.
Pool di identità di parchi risorse e progetti
Per capire perché la federazione delle identità per i carichi di lavoro a livello di parco risorse richiede un'adozione attenta, in particolare quando si utilizzano parchi risorse multi-project, diamo un'occhiata più da vicino al funzionamento della federazione delle identità per i carichi di lavoro standard per GKE e della federazione delle identità per i carichi di lavoro del parco risorse. In entrambi i casi, i carichi di lavoro si autenticano utilizzando token di breve durata generati dai cluster, con ogni cluster aggiunto come provider di identità a un pool di identità dei carichi di lavoro speciale. I carichi di lavoro in esecuzione in uno spazio dei nomi specifico possono quindi condividere la stessa identità IAM nei cluster.
Ecco cosa succede con la normale federazione delle identità per i carichi di lavoro per GKE quando è abilitata per i tuoi cluster. Tieni presente che la federazione delle identità per i carichi di lavoro per GKE è abilitata per i cluster Autopilot per impostazione predefinita.
- GKE crea un pool di identità per i carichi di lavoro gestito da Google nel progetto del cluster:
PROJECT_ID.svc.goog.id. - GKE aggiunge i cluster come provider di identità al pool.
- Di conseguenza, i carichi di lavoro in esecuzione in uno spazio dei nomi specifico condividono la stessa identità IAM nei cluster di un progetto. L'identità è in questo formato:
serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME].
La federazione delle identità per i carichi di lavoro a livello di parco risorse viene attivata automaticamente quando aggiungi un cluster con la federazione delle identità per i carichi di lavoro per GKE abilitata a un parco risorse, inclusi i cluster Autopilot, i cluster standard con la funzionalità abilitata esplicitamente e i cluster GKE esterni a Google Cloud.
Ecco cosa succede quando un utente registra un cluster con la federazione delle identità per i carichi di lavoro per GKE abilitata in un parco risorse:
- Se non esiste già, viene creato il pool di identità del workload a livello di parco risorse
FLEET_PROJECT_ID.svc.goog.idgestito da Google nel progetto host del parco risorse. È lo stesso del pool di identità del workload del progetto per il progetto host del parco risorse. - Il cluster viene aggiunto come provider di identità al pool.
- Di conseguenza, i carichi di lavoro in esecuzione in uno spazio dei nomi specifico condividono la stessa identità IAM nei cluster del parco risorse. Si tratta della uguaglianza implicita delle identità del carico di lavoro del parco risorse. L'identità è in questo formato:
serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]. I workload del parco risorse in progetti diversi possono quindi chiamare le API di Google utilizzando la stessa identità per l'autenticazione.
Come suggerisce, se il parco risorse include solo i cluster di un progetto e sono tutti registrati al parco risorse, il risultato è lo stesso che se utilizzassi solo la federazione delle identità per i carichi di lavoro per GKE senza parchi risorse: tutti i cluster sono provider di identità nel pool di identità dei carichi di lavoro a livello di progetto e i carichi di lavoro utilizzano le stesse identità che userebbero con la federazione delle identità per i carichi di lavoro per GKE. Tuttavia, quando il parco risorse ha cluster membri in più progetti, la federazione delle identità per i carichi di lavoro del parco risorse combina i pool di identità per progetto in un unico pool di identità a livello di parco risorse, ospitato nel progetto host del parco risorse.
Come vedrai nei seguenti esempi, possono verificarsi alcune complessità quando esiste solo una sovrapposizione parziale tra l'insieme di cluster in un progetto e l'insieme di cluster in quel progetto che fanno parte di un parco risorse.
Scenario 1: parco risorse di un singolo progetto con tutti i cluster registrati
In questo scenario, tutti i cluster membri del parco risorse si trovano nel progetto host del parco risorse e tutti i cluster del progetto fanno parte del parco risorse.
Come descritto nella sezione precedente, l'utilizzo della federazione delle identità per i carichi di lavoro a livello di parco risorse in questo scenario è equivalente all'utilizzo della normale federazione delle identità per i carichi di lavoro per GKE e non comporta rischi aggiuntivi.
Scenario 2: parco risorse di un singolo progetto con alcuni cluster registrati
In questo scenario, un parco risorse contiene due cluster, entrambi nel progetto host del parco risorse Progetto 1. Il progetto host del parco risorse contiene anche un terzo cluster che non è un membro del parco risorse e in cui è abilitata la federazione delle identità per i carichi di lavoro per GKE.
Ciò significa che:
- I cluster 1, 2 e 3 vengono aggiunti da GKE al pool Workload Identity del progetto
project-1.svc.goog.id. - I cluster 1 e 2 vengono aggiunti dal parco risorse al pool di identità del workload del parco risorse, che (poiché si tratta del progetto host del parco risorse) è anche il pool di identità del workload del progetto
project-1.svc.goog.id.
L'amministratore vuole concedere autorizzazioni ai carichi di lavoro in esecuzione in uno spazio dei nomi in tutti i cluster del parco risorse. Utilizzano serviceAccount:project-1.svc.goog.id[namespace/ksa] come identità per concedere l'accesso. Tuttavia, i carichi di lavoro nello spazio dei nomi del cluster 3, che non fa parte del parco risorse, ora condividono lo stesso accesso. Questo accade perché il cluster 3 si trova nel pool di identità dei workload del progetto, che (poiché si tratta del progetto host del parco risorse) è uguale al pool di identità dei workload del parco risorse. In altre parole, l'amministratore potrebbe voler concedere le autorizzazioni solo ai cluster di un parco risorse, ma, data l'implementazione della federazione delle identità per i carichi di lavoro del parco risorse, anche i cluster non appartenenti al parco risorse potrebbero ottenere l'accesso.
Possibile mitigazione
Una possibile soluzione è creare un progetto dedicato per ospitare il parco risorse senza cluster, applicato da Custom Org Policy nell'API container. In questo modo, il dominio attendibile del pool di identità del workload del parco risorse è separato dai domini attendibili a livello di progetto GKE.
L'amministratore può quindi scegliere il dominio attendibile appropriato quando concede le autorizzazioni ai carichi di lavoro. Ad esempio, possono utilizzare serviceAccount:project-0.svc.goog.id[namespace/ksa] per concedere autorizzazioni a un carico di lavoro con spazio dei nomi in tutto il parco risorse. Il cluster 3 non appartenente al parco non fa parte del pool di identità del carico di lavoro in questa configurazione e quindi non ottiene l'accesso.
Questa soluzione è valida per i cluster su Google Cloud e per i cluster collegati.
Scenario 3: parco risorse multi-progetto con alcuni cluster registrati
In questo scenario, un parco risorse ha membri di due progetti, Progetto 1 e Progetto 2.
L'amministratore vuole concedere autorizzazioni ai carichi di lavoro in esecuzione in uno spazio dei nomi in tutti i cluster del progetto 1 utilizzando la normale federazione Workload Identity per GKE. Tuttavia, poiché il cluster 4 è registrato nel parco risorse e il progetto 1 è il progetto host del parco risorse, anche i workload sul cluster 4 nel progetto 2 riceveranno le stesse autorizzazioni.
Possibile mitigazione
Come nello scenario precedente, una possibile soluzione è creare un progetto host del parco risorse dedicato senza cluster. Anche in questo caso, l'amministratore può distinguere le identità del pool di identità del parco e quelle del pool di identità del progetto di ogni cluster durante la configurazione del controllo dell'accesso dell'accesso.
Scenario 4: prendi in considerazione l'uguaglianza dello spazio dei nomi
I pool di identità per i carichi di lavoro non sono l'unica potenziale area di confusione quando si utilizza la federazione delle identità per i carichi di lavoro. Come saprai da Pianificare le funzionalità del parco risorse, molte funzionalità del parco risorse, inclusa la federazione di Workload Identity del parco risorse, presuppongono l'identità dello spazio dei nomi per semplificare la configurazione e la gestione del parco risorse. Ciò significa che la funzionalità tratta gli spazi dei nomi con lo stesso nome in più cluster membri del parco risorse come se fossero lo stesso spazio dei nomi. In questo esempio, un amministratore ha concesso autorizzazioni ai carichi di lavoro nello spazio dei nomi NS1 in esecuzione sui cluster membri del parco Cluster 1 e Cluster 2.
Tuttavia, un utente ha creato (accidentalmente o intenzionalmente) uno spazio dei nomi con lo stesso nome in un altro cluster di membri del parco. A causa dell'assunzione di identità dello spazio dei nomi, i carichi di lavoro in questo spazio dei nomi acquisiscono automaticamente gli stessi privilegi dei carichi di lavoro NS1 legittimi nel cluster 1 e nel cluster 2.
Possibile mitigazione
Imposta le autorizzazioni in modo che solo un piccolo gruppo di ruoli attendibili possa creare spazi dei nomi nei cluster.