Ridurre i rischi di identità identiche nelle flotte multi-tenant

Questa pagina fornisce le best practice per la configurazione e l'utilizzo di Workload Identity Federation del parco risorse, una funzionalità del parco risorse che consente di configurare centralmente l'autenticazione dalle applicazioni alle Google Cloud API tra i progetti. Per le best practice sull'adozione di altre funzionalità del parco risorse, consulta Pianificare le funzionalità del parco risorse.

Questa pagina è destinata agli amministratori e agli operatori della piattaforma e agli ingegneri della sicurezza che vogliono ridurre al minimo i rischi associati all'identità identica nei parchi risorse.

Prima di leggere questa pagina, assicurati di conoscere i concetti descritti in Informazioni sulla federazione delle identità per i workload del parco risorse.

Terminologia

In questa pagina viene utilizzata la seguente terminologia:

  • Workload Identity Federation for GKE: una funzionalità che fornisce identità ai workload GKE in un singolo Google Cloud progetto.
  • Federazione delle identità per i workload del parco risorse: una funzionalità che estende Workload Identity Federation for GKE ai workload dell'intero parco risorse, inclusi quelli esterni Google Cloud e tra 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à del workload.

Identità identica nei parchi risorse

I pool di identità del 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 for GKE, ogni progetto ha per impostazione predefinita un pool di identità del workload gestito da Google fisso e univoco per quel progetto.

Con la federazione delle identità per i workload del parco risorse, il pool di identità del workload gestito da Google per il progetto host del parco risorse è il pool di identità del workload predefinito per tutti i cluster registrati nel parco risorse, indipendentemente dal fatto che i cluster si trovino in altri progetti o in altri cloud. Facoltativamente, puoi configurare un pool di identità del workload autogestito da utilizzare per cluster specifici anziché il pool predefinito.

Sia in Workload Identity Federation del parco risorse sia in Workload Identity Federation for GKE, utilizzi i criteri di autorizzazione IAM per concedere ruoli a entità specifiche Google Cloud risorse nei cluster, come ServiceAccount o pod Kubernetes. Nei criteri di autorizzazione, fai riferimento a queste entità utilizzando un identificatore dell'entità, ovvero una sintassi di denominazione che IAM può leggere. L'identificatore dell'entità include il nome del pool di identità del workload utilizzato dal cluster e altre informazioni che selezionano le entità specifiche nel cluster. Ad esempio, il seguente identificatore dell'entità seleziona un ServiceAccount 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 sull'entità:

  • PROJECT_NUMBER: il numero del progetto host 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 ServiceAccount 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 dell'entità che ha creato la richiesta. IAM utilizza l'identificatore dell'entità per assicurarsi che un criterio di autorizzazione autorizzi l'entità a eseguire l'operazione richiesta.

Implicazioni dell'identità identica per i parchi risorse multi-tenant

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

Ad esempio, con l'identificatore dell'entità nella sezione precedente, le richieste dai pod che utilizzano lo stesso ServiceAccount, lo stesso spazio dei nomi e lo stesso pool di identità del workload ricevono lo stesso identificatore dell'entità indipendentemente dal cluster o dal progetto.

Se il parco risorse esegue solo cluster nel progetto host del parco risorse, le implicazioni dell'identità identica sono le stesse di Workload Identity Federation for GKE. Tuttavia, se il parco risorse ha cluster in esecuzione in altri progetti, l'identità identica si estende a tutti i cluster registrati nel parco risorse.

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

I seguenti scenari di esempio descrivono le potenziali complessità dell'identità identica che possono verificarsi quando implementi la federazione delle identità per i workload del parco risorse. Ogni scenario fornisce possibili mitigazioni che potrebbero aiutarti a gestire queste complessità.

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

Considera 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 sono membri del parco risorse.
  • Tutti i cluster utilizzano lo stesso pool di identità del workload.

In questo scenario, tutti i cluster membri del parco risorse si trovano nel progetto host del parco risorse e tutti i cluster di questo progetto sono membri del parco risorse.

Diagramma che mostra un progetto con tutti i cluster nella stessa flotta

Come descritto nella sezione Implicazioni dell'identità identica per i parchi risorse , l'utilizzo della federazione delle identità per i workload del parco risorse in questo scenario è uguale all'utilizzo di Workload Identity Federation for GKE e non comporta rischi aggiuntivi.

Parco risorse a progetto singolo con alcuni cluster registrati e lo stesso pool di identità del workload

Considera 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 Workload Identity Federation for GKE.
  • Tutti i cluster del progetto utilizzano lo stesso pool di identità del workload.

Diagramma che mostra un progetto con alcuni cluster nello stesso parco risorse.

Con questa configurazione, tutti i ruoli che concedi a un'entità in un cluster del progetto si applicano ad altre entità del progetto che corrispondono all'identificatore dell'entità. In questo modo, potresti concedere involontariamente autorizzazioni a entità che non fanno parte del parco risorse. Ad esempio, la concessione di un ruolo a un identificatore dell'entità che seleziona un account di servizio specifico in uno spazio dei nomi ha le seguenti implicazioni:

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

I seguenti suggerimenti potrebbero aiutarti a risolvere questa complessità:

  • Configura i cluster membri del parco risorse in modo che utilizzino un pool di identità del workload autogestito. In questo modo, le entità nei cluster membri del parco risorse hanno identificatori dell'entità diversi dal cluster non membro. Per i dettagli, consulta Autenticare le API dai workload del parco risorse con attendibilità mista. Google Cloud

  • Crea un progetto host del parco risorse dedicato e utilizza i criteri dell'organizzazione per impedire l'esecuzione di cluster nel progetto host del parco risorse dedicato. In questo modo, il dominio di trust del pool di identità del workload a livello di parco risorse viene separato dai domini di trust a livello di progetto GKE. Solo i cluster registrati condividono il pool di identità del workload a livello di parco risorse.

    Questi suggerimenti funzionano per i cluster su Google Cloud e i cluster collegati.

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

Considera la seguente configurazione del parco risorse:

  • Il parco risorse contiene cluster membri in esecuzione in due Google Cloud progetti: project-1 e project-2.
  • project-1 è il progetto host del parco risorse. Tutti i cluster in project-1 sono membri 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 identità del workload gestito da Google del progetto, che è anche il pool di identità del workload predefinito a livello di parco risorse.
  • Il cluster membro del parco risorse in project-2 utilizza il pool di identità del workload a livello di parco risorse.

Diagramma che mostra un parco risorse con cluster di due progetti.

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

Per risolvere questa complessità, crea un progetto dedicato Google Cloud project da utilizzare come progetto host del parco risorse. Per impostazione predefinita, i cluster membri del parco risorse in project-1 e in project-2 condividono il pool di identità del workload del progetto dedicato. Puoi quindi concedere l'accesso con ambito progetto ai cluster in project-1 utilizzando il pool di identità del workload per project-1 nell'identificatore dell'entità.

Impedire la creazione di identità simili

L'identità identica nei parchi risorse richiede di implementare attentamente il controllo 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 ServiceAccount specifico in uno spazio dei nomi. Se qualcuno crea lo spazio dei nomi e il ServiceAccount in un cluster membro del parco risorse diverso, i pod in quel cluster ottengono lo stesso accesso.

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

  • Per IAM, le seguenti autorizzazioni forniscono questo accesso:

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

  • Per il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes, i seguenti ClusterRole di esempio configurano l'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