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

Questa pagina fornisce le best practice per la configurazione e l'utilizzo della federazione delle identità per i carichi di lavoro del parco risorse, una funzionalità del parco risorse che consente di configurare centralmente l'autenticazione dalle applicazioni alle API nei vari progetti. Google Cloud 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à nelle flotte.

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:

  • Federazione delle identità per i carichi di lavoro per GKE: una funzionalità che fornisce identità ai workload GKE in un singolo progetto Google Cloud .
  • Federazione delle identità per i carichi di lavoro della flotta: una funzionalità che estende la federazione delle identità per i carichi di lavoro per GKE ai carichi di lavoro dell'intera flotta, anche al di fuori di Google Cloud e 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à del workload.

Identità identiche 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 la federazione delle identità per i carichi di lavoro per GKE, per impostazione predefinita ogni progetto ha un pool di identità dei carichi di lavoro gestito da Google 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 host del parco risorse è il pool di identità per i carichi di lavoro predefinito per tutti i cluster che registri nel parco risorse, indipendentemente dal fatto che i cluster si trovino in altri progetti o altri cloud. Puoi anche configurare un pool di identità dei workload autogestito per cluster specifici da utilizzare al posto del pool predefinito.

Sia nella federazione delle identità per i carichi di lavoro della flotta sia nella federazione delle identità per i carichi di lavoro per GKE, utilizzi i criteri di autorizzazione IAM per concedere ruoli su risorse Google Cloud specifiche alle entità nei tuoi cluster, come ServiceAccount Kubernetes o pod. Nelle norme 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 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 sul mandante:

  • PROJECT_NUMBER: il numero di progetto del progetto host del parco veicoli.
  • 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 dell'entità per garantire che un criterio di autorizzazione autorizzi l'entità a eseguire l'operazione richiesta.

Implicazioni dell'identità per le flotte 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 la stessa cosa da IAM. 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 di Workload Identity del parco risorse, questa identità identica 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 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 ottengono lo stesso identificatore dell'entità indipendentemente dal cluster o dal progetto.

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, l'identità è la stessa per tutti i cluster registrati nel parco risorse.

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

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

Parco risorse con un solo progetto 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 nel 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à per i parchi risorse, l'utilizzo della federazione delle identità per i carichi di lavoro del parco risorse in questo scenario equivale all'utilizzo della federazione delle identità per i carichi di lavoro per GKE e non comporta rischi aggiuntivi.

Parco risorse con un solo progetto 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.
  • Nel cluster che non è un membro del parco risorse è abilitata anche la federazione delle identità per i carichi di lavoro per GKE.
  • Tutti i cluster nel 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 principale. Ciò potrebbe comportare la concessione involontaria di autorizzazioni a entità che non fanno parte della flotta. Ad esempio, la concessione di un ruolo a un identificatore entità che seleziona un account di servizio specifico in uno spazio dei nomi ha le seguenti implicazioni:

  • I workload eseguiti nello spazio dei nomi specificato e che utilizzano l'account di servizio specificato nei cluster membri del parco risorse condividono l'accesso.
  • I workload eseguiti nel terzo cluster non membro che utilizzano lo stesso spazio dei nomi e lo stesso nome del 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à del workload autogestito (anteprima). In questo modo, le entità nei cluster membri del parco risorse hanno identificatori principali diversi da quelli del cluster non membro. Per maggiori dettagli, vedi Autenticarsi alle API Google Cloud dai workload del parco risorse con attendibilità mista.

  • Crea un progetto host del parco risorse dedicato e utilizza le policy dell'organizzazione per impedire l'esecuzione di cluster nel progetto host del parco risorse dedicato. In questo modo il dominio attendibile del pool di identità dei 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à del workload a livello di 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à del workload

Considera la seguente configurazione del parco risorse:

  • Il parco risorse contiene cluster membri che vengono eseguiti in due progetti: Google Cloud, 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 a partire dal giorno project-2, perché condividono tutte lo stesso pool di identità del workload.

Per cercare di risolvere questa complessità, crea un progetto Google Cloud dedicato da utilizzare come progetto host del parco risorse. I cluster membri del parco risorse in project-1 e in project-2 condividono per impostazione predefinita il pool di identità del workload del progetto dedicato. Puoi quindi concedere l'accesso con ambito di 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 nelle flotte richiede un'attenta implementazione 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 ServiceAccount specifico in uno spazio dei nomi. Se qualcuno crea questo spazio dei nomi e questo 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 controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes, i seguenti esempi ClusterRole 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