Prima di leggere questa guida, devi conoscere i concetti descritti in Eseguire l'autenticazione in API e servizi dai carichi di lavoro 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 comprendere perché la federazione delle identità per i carichi di lavoro a livello di parco risorse richiede un'adozione accurata, in particolare quando si lavora con parchi risorse multiprogetto, diamo un'occhiata più da vicino a come funzionano la federazione delle identità dei carichi di lavoro standard per GKE e la federazione delle identità dei carichi di lavoro del parco risorse. In entrambi i casi, i carichi di lavoro vengono autenticati mediante token di breve durata generati dai cluster, con ogni cluster aggiunto come provider di identità a uno speciale pool di identità per i carichi di lavoro. I carichi di lavoro in esecuzione in uno spazio dei nomi specifico possono quindi condividere la stessa identità IAM nei cluster.
Ecco cosa succede alla 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 impostazione predefinita per i cluster Autopilot.
- 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 al pool come provider di identità.
- 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 abilitata automaticamente quando aggiungi un cluster con federazione delle identità per i carichi di lavoro per GKE abilitata a un parco risorse, inclusi cluster Autopilot, cluster standard con la funzionalità abilitata esplicitamente e 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à di carico di lavoro 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à per i carichi di lavoro del progetto host del parco risorse. - Il cluster viene aggiunto al pool come provider di identità.
- Di conseguenza, i carichi di lavoro in esecuzione in uno spazio dei nomi specifico condividono la stessa identità IAM nei cluster del parco risorse. Questo è un concetto come uguaglianza implicita delle identità dei carichi di lavoro del parco risorse. L'identità è in questo formato:
serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]. I carichi di lavoro del parco risorse in progetti diversi possono quindi chiamare le API di Google utilizzando la stessa identità per l'autenticazione.
Come suggerisce questo esempio, se il parco risorse include solo cluster di un progetto e sono tutti registrati nel parco risorse, il risultato è lo stesso di utilizzare 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 utilizzerebbero con la federazione delle identità per i carichi di lavoro per GKE. Tuttavia, quando il parco risorse ha cluster membro 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 negli esempi seguenti, possono verificarsi alcune complessità in cui esiste solo una sovrapposizione parziale tra l'insieme di cluster di un progetto e l'insieme di cluster di un progetto che fanno parte di un parco.
Scenario 1: parco risorse di progetti singolo 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 in quel progetto sono membri 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 equivale all'utilizzo della federazione delle identità per i carichi di lavoro standard per GKE, senza alcun rischio aggiuntivo.
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 è membro del parco risorse, per il quale è 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 di identità dei carichi di lavoro del progetto
project-1.svc.goog.id. - I cluster 1 e 2 vengono aggiunti dal parco risorse al pool di identità per i carichi di lavoro del parco risorse, che (poiché si tratta del progetto host del parco risorse) è anche il pool di identità per i carichi di lavoro 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 perché il cluster 3 si trova nel pool di identità dei carichi di lavoro del progetto, che (perché questo è il progetto host del parco risorse) è uguale al pool di identità del carico di lavoro 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 dai criteri dell'organizzazione personalizzati nell'API container. In questo modo viene fornita una chiara separazione del dominio di attendibilità del pool di identità per i carichi di lavoro del parco risorse dai domini di attendibilità 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 del membro non del parco risorse non fa parte del pool di identità per i carichi di lavoro in questa configurazione e, di conseguenza, non ottiene l'accesso.
Questa soluzione funziona per i cluster su Google Cloud e 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 vorrebbe concedere le autorizzazioni ai carichi di lavoro in esecuzione in uno spazio dei nomi in tutti i cluster del progetto 1, utilizzando la normale federazione delle identità per i carichi di lavoro per GKE. Tuttavia, poiché il cluster 4 è registrato nel parco risorse e il progetto 1 è il progetto host del parco risorse, anche i carichi di lavoro sul cluster 4 nel progetto 2 avranno le stesse autorizzazioni.
Possibile soluzione
Come nello scenario precedente, una possibile mitigazione qui è 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 ciascun cluster durante la configurazione del controllo 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 in Pianifica funzionalità del parco risorse, molte funzionalità del parco risorse, inclusa la federazione delle identità per i carichi di lavoro, utilizzano il presupposto dell'identicità dello spazio dei nomi per semplificare la configurazione e la gestione in tutto il parco risorse. Ciò significa che la funzionalità tratta gli spazi dei nomi con lo stesso nome in più cluster membro 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. Presupponendo l'identicità dello spazio dei nomi, i carichi di lavoro in quello spazio dei nomi ottengono automaticamente gli stessi privilegi dei carichi di lavoro NS1 legittimi nei cluster 1 e 2.
Possibile mitigazione
Imposta le autorizzazioni in modo che solo un piccolo gruppo di ruoli attendibili possa creare spazi dei nomi nei cluster.