Riduci i rischi di identità uguali nei parchi multi-tenant

Questa pagina è rivolta agli amministratori e agli operatori della piattaforma e agli addetti alla sicurezza che vogliono ridurre al minimo i rischi associati all'identità uguale nei parchi.

Prima di leggere questa pagina, assicurati di conoscere i concetti descritti in Informazioni sulla federazione di Workload Identity del parco risorse.

Terminologia

Questa pagina utilizza la seguente terminologia:

• Workload Identity Federation for GKE: una funzionalità che fornisce identità ai workload GKE in un unico Google Cloud progetto.
• Federazione delle identità per i carichi di lavoro del parco risorse: una funzionalità che estende la federazione delle identità per i carichi di lavoro per GKE ai carichi di lavoro dell'intero parco risorse, inclusi quelli esterni a Google Cloude in più progetti.
• Pool di identità del workload: un'entità che fornisce identità ai workload in un formato compatibile con Identity and Access Management (IAM). Ogni cluster è un provider di identità in un pool di identità di Workload Identity.

Identità uguali nei parchi risorse

I pool di identità dei workload sono entità che forniscono identità ai workload in un formato che IAM può utilizzare per autenticare e autorizzare le richieste. Con Workload Identity Federation per GKE, per impostazione predefinita ogni progetto ha un pool di identità per i carichi di lavoro fisso e gestito da Google che è univoco per quel progetto.

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 per il progetto di hosting del parco risorse è il pool di identità per i carichi di lavoro predefinito per tutti i cluster registrati nel parco risorse, indipendentemente dal fatto che si trovino in altri progetti o in altri cloud. Facoltativamente, puoi configurare un pool di identità per i carichi di lavoro autogestiti da utilizzare per cluster specifici anziché per il pool predefinito.

Sia nella federazione delle identità per i carichi di lavoro del parco risorse sia nella federazione delle identità per i carichi di lavoro per GKE, utilizzi i criteri di autorizzazione IAM per concedere ruoli su risorse Google Cloudspecifiche alle entità dei tuoi cluster, ad esempio gli account di servizio o i pod Kubernetes. Nei criteri di autorizzazione, fai riferimento a queste entità utilizzando un identificatore principale, ovvero una sintassi di denominazione che IAM può leggere. L'identificatore principale include il nome del pool di identità dei carichi di lavoro utilizzato dal cluster e altre informazioni che selezionano le entità specifiche nel cluster. Ad esempio, il seguente identificatore principale seleziona un account di servizio Kubernetes in uno spazio dei nomi:

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

In questo esempio, i seguenti campi contengono informazioni sul principale:

• PROJECT_NUMBER: il numero del progetto del parco risorse.
• WORKLOAD_IDENTITY_POOL_NAME: il nome del pool di identità del workload.
• NAMESPACE: il nome dello spazio dei nomi.
• SERVICEACCOUNT: il nome del service account Kubernetes.

Le richieste alle Google Cloud API vengono autenticate utilizzando token di accesso OAuth 2.0 di breve durata generati dai cluster. Questi token di accesso includono l'identificatore principale dell'entità che ha creato la richiesta. IAM utilizza l'identificatore principale per garantire che un criterio di autorizzazione autorizzi l'entità a eseguire l'operazione richiesta.

Implicazioni dell'identità uguale per i fleet multi-tenant

L'identificatore dell'entità genera identità uguali, il che significa che qualsiasi entità nell'ambiente che corrisponde a un identificatore dell'entità specifico è considerata da IAM come la stessa cosa. Con la federazione delle identità per i carichi di lavoro per GKE per un singolo progetto, l'identità uguale si applica a tutte le entità che condividono un identificatore principale in quel progetto. Tuttavia, con la federazione di Workload Identity del parco risorse, questa identità uguale si applica a tutte le entità che condividono un identificatore principale nell'intero parco risorse, indipendentemente dal progetto del cluster.

Ad esempio, con l'identificatore principale nella sezione precedente, le richieste provenienti da pod che utilizzano lo stesso account di servizio, lo stesso spazio dei nomi e lo stesso pool di identità di workload ricevono lo stesso identificatore principale indipendentemente dal cluster o dal progetto.

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, l'identità uguale si estende a tutti i cluster registrati nel parco risorse.

Esempi di complessità per l'identità del parco risorse

Gli scenari di esempio riportati di seguito descrivono le potenziali complessità di identità uguali che possono verificarsi quando implementi la federazione Workload Identity del parco risorse. Ogni scenario fornisce possibili mitigazioni che potrebbero aiutarti a gestire queste complessità.

Parco risorse di un singolo progetto con tutti i cluster registrati e lo stesso pool di identità di workload

Prendi in considerazione la seguente configurazione del parco risorse:

• Tutti i cluster membri del parco risorse si trovano nel progetto host del parco risorse.
• Tutti i cluster del progetto fanno parte del parco risorse.
• Tutti i cluster utilizzano lo stesso pool di identità di workload.

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 Implicazioni dell'identità uguale per i parchi risorse, l'utilizzo della federazione delle identità per i carichi di lavoro del parco risorse in questo scenario è uguale all'utilizzo della federazione delle identità per i carichi di lavoro per GKE e non comporta rischi aggiuntivi.

Parco risorse di un singolo progetto con alcuni cluster registrati e lo stesso pool di identità per i carichi di lavoro

Prendi in considerazione la seguente configurazione del parco risorse:

• Il parco risorse contiene due cluster, entrambi in esecuzione nel progetto host del parco risorse.
• Il progetto host del parco risorse contiene un terzo cluster che non è un membro del parco risorse.
• Anche il cluster che non è un membro del parco risorse ha abilitato la federazione delle identità per i carichi di lavoro per GKE.
• Tutti i cluster del progetto utilizzano lo stesso pool di identità di carico di lavoro

Con questa configurazione, tutti i ruoli concessi a un'entità in un cluster del progetto vengono applicati alle altre entità del progetto che corrispondono all'identificatore principale. Ciò potrebbe comportare l'assegnazione involontaria di autorizzazioni a persone giuridiche che non fanno parte del parco veicoli. Ad esempio, la concessione di un ruolo a un identificatore di entità che seleziona un account di servizio specifico in uno spazio dei nomi ha le seguenti implicazioni:

• I carichi di lavoro che vengono eseguiti nello spazio dei nomi specificato e utilizzano l'account di servizio specificato nei cluster dei membri del parco condividono l'accesso.
• Anche i workload in esecuzione nel terzo cluster non membro che utilizzano lo stesso spazio dei nomi e lo stesso nome dell'account di servizio ottengono lo stesso accesso.

I seguenti suggerimenti potrebbero aiutarti a risolvere questo problema:

• Configura i cluster membri del parco risorse in modo che utilizzino un pool di identità di workload autogestite (anteprima). In questo modo, le entità nei cluster di membri del parco risorse hanno identificativi principali diversi da quelli del cluster di non membri. Per maggiori dettagli, consulta Eseguire l'autenticazione alle API Google Cloud dai workload dei parchi risorse con attendibilità mista.

• Crea un progetto host del parco risorse dedicato e utilizza le norme dell'organizzazione per impedire al progetto host del parco risorse dedicato di eseguire cluster. In questo modo, il dominio attendibile del pool di identità per i carichi di lavoro a livello di parco risorse viene separato dai domini attendibili a livello di progetto GKE. Solo i cluster registrati condividono il pool di identità di carico di lavoro per l'intero parco risorse.

  Questi suggerimenti sono validi per i cluster su Google Cloud e per i cluster collegati.

Parco risorse multi-progetto con alcuni cluster registrati e lo stesso pool di identità di workload

Prendi in considerazione la seguente configurazione del parco risorse:

• Il parco risorse contiene cluster membri che vengono eseguiti in due Google Cloud progetti: project-1 e project-2.
• project-1 è il progetto host del parco risorse. Tutti i cluster in project-1 fanno parte del parco risorse.
• project-2 contiene un cluster membro del parco risorse e un cluster non registrato.
• Tutti i cluster in project-1 utilizzano il pool di Workload Identity gestito da Google del progetto, che è anche il pool di Workload Identity predefinito per l'intero parco risorse.
• Il cluster membro del parco risorse in project-2 utilizza il pool di identità per i carichi di lavoro a livello di parco risorse.

In questo scenario, tutte le autorizzazioni concesse alle entità nel progetto del parco risorse ospitante si applicano anche alle entità nel cluster membro di project-2, perché tutte condividono lo stesso pool di identità di carico di lavoro.

Per provare a risolvere questa complessità, crea un progetto Google Cloud dedicato da utilizzare come progetto host del parco risorse. I cluster dei membri del parco risorse in project-1 e in project-2 condividono quindi per impostazione predefinita il pool di identità dei carichi di lavoro del progetto dedicato. Puoi quindi concedere l'accesso a livello di progetto ai cluster in project-1 utilizzando il pool di identità di lavoro per project-1 nell'identificatore principale.

Impedire la creazione di identità simili

L'identità uguale nei parchi richiede l'implementazione attenta del controllo dell'accesso dell'accesso per impedire la creazione intenzionale o involontaria di identità simili. Ad esempio, considera uno scenario in cui concedi l'accesso a tutti i pod che utilizzano un account di servizio specifico in uno spazio dei nomi. Se qualcuno crea lo spazio dei nomi e il servizio account in un altro cluster membro del parco risorse, i pod in quel cluster ottengono lo stesso accesso.

Per ridurre le probabilità di questo problema, utilizza un meccanismo di autorizzazione per consentire solo a un insieme attendibile di utenti di creare, aggiornare o eliminare gli spazi dei nomi e gli account di servizio Kubernetes.

• Per IAM, le seguenti autorizzazioni forniscono questo accesso:

  • container.namespaces.*
  • container.serviceAccounts.*

• Per controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes, i seguenti esempi di ruoli di gruppo configurano un accesso speciale per interagire con queste risorse Kubernetes:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: namespace-admin
  rules:
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["create","delete","update","patch"]
  ---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: serviceaccount-admin
  rules:
  - apiGroups: [""]
    resources: ["serviceaccounts"]
    verbs: ["create","delete","update","patch","impersonate"]
  

Passaggi successivi

• Gestire le funzionalità a livello di parco risorse
• Proteggi il tuo parco risorse