Workload Identity

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Workload Identity è il metodo consigliato ai tuoi carichi di lavoro in esecuzione su Google Kubernetes Engine (GKE) per accedere ai servizi Google Cloud in modo sicuro e gestibile.

Per ulteriori informazioni su come abilitare e utilizzare Workload Identity in GKE, consulta Utilizzare Workload Identity.

Puoi utilizzare l'identità del carico di lavoro del parco risorse per fornire il supporto della federazione dell'identità del carico di lavoro per i cluster registrati nei flessi, inclusi i cluster Anthos.

Terminologia

Questo documento distingue tra account di servizio Kubernetes e account di servizio Identity and Access Management (IAM).

Account di servizio Kubernetes
Risorse Kubernetes che forniscono un'identità per i processi in esecuzione nei tuoi pod GKE.
Account di servizio IAM
Risorse Google Cloud che consentono alle applicazioni di effettuare chiamate autorizzate alle API Google Cloud.

Che cos'è Workload Identity?

Le applicazioni in esecuzione su GKE potrebbero dover accedere alle API Google Cloud, come l'API Compute Engine, l'API BigQuery Storage o le API di machine learning.

Workload Identity consente a un account di servizio Kubernetes nel tuo cluster GKE di agire come account di servizio IAM. I pod che utilizzano l'account di servizio Kubernetes configurato autenticano automaticamente come account di servizio IAM quando accedono alle API Google Cloud. Con Workload Identity puoi assegnare autorizzazioni e identità granulari distinte per ogni applicazione nel tuo cluster.

Come funziona Workload Identity

Quando abiliti Workload Identity in un cluster, GKE crea automaticamente un pool di identità del carico di lavoro fisso per il progetto Google Cloud del cluster con il seguente formato:

PROJECT_ID.svc.id.goog

Il pool di identità del carico di lavoro fornisce un formato di denominazione che consente a IAM di comprendere e considerare attendibili le credenziali dell'account di servizio Kubernetes. L'abilitazione di Workload Identity non concede ai tuoi carichi di lavoro autorizzazioni IAM per impostazione predefinita.

Quando configuri un account di servizio Kubernetes in uno spazio dei nomi per utilizzare Workload Identity, IAM autentica le credenziali utilizzando il seguente nome membro:

serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KUBERNETES_SERVICE_ACCOUNT]

In questo nome membro:

  • PROJECT_ID: il tuo ID progetto Google Cloud.
  • KUBERNETES_NAMESPACE: lo spazio dei nomi dell'account di servizio Kubernetes.
  • KUBERNETES_SERVICE_ACCOUNT: nome dell'account di servizio Kubernetes che effettua la richiesta.

Il processo di configurazione di Workload Identity prevede l'utilizzo di un'associazione dei criteri IAM per associare il nome del membro dell'account di servizio Kubernetes a un account di servizio IAM con le autorizzazioni necessarie per i carichi di lavoro. Qualsiasi chiamata all'API Google Cloud proveniente dai carichi di lavoro che utilizzano questo account di servizio Kubernetes viene autenticata come account di servizio IAM associato.

Identità dell'identità

Il nome del membro utilizzato da IAM per verificare un account di servizio Kubernetes con Workload Identity utilizza le seguenti variabili:

  • Il nome dell'account di servizio Kubernetes.
  • Lo spazio dei nomi dell'account di servizio Kubernetes.
  • ID del progetto Google Cloud.

Se il tuo progetto ha più cluster che hanno lo stesso nome e spazio dei nomi per un account di servizio Kubernetes, tutti gli account vengono risolti con lo stesso nome del membro. Questa identità comune consente di concedere l'accesso alle risorse Google Cloud al pool di identità del carico di lavoro anziché ai singoli cluster.

Ad esempio, considera il seguente diagramma. I cluster A, B, e C appartengono allo stesso progetto Google Cloud, quindi allo stesso pool di identità dei carichi di lavoro. Le applicazioni nello spazio dei nomi backend sia del cluster A che del cluster B possono autenticarsi come account di servizio IAM back quando accedono alle risorse Google Cloud. IAM non distingue tra i cluster che effettuano le chiamate.

Diagramma che illustra la stessa identità all'interno di un pool di identità del carico di lavoro
Identità dell'identità che accede alle API Google Cloud con Workload Identity

Questa identità di identità significa anche che devi poter considerare attendibile ogni cluster in un pool di identità del carico di lavoro specifico. Ad esempio, se il cluster C nell'esempio precedente era di proprietà di un team non attendibile, potrebbe creare uno spazio dei nomi backend e accedere alle API Google Cloud utilizzando l'account di servizio IAM back, proprio come il Cluster A e il Cluster B.

Per evitare l'accesso non attendibile, colloca i cluster in progetti separati per assicurarti che ricevano pool di identità dei carichi di lavoro diversi o fai in modo che i nomi degli spazi dei nomi siano diversi tra loro per evitare un nome membro comune.

Informazioni sul server metadati GKE

Ogni nodo in un GKE con Workload Identity abilitato archivia i propri metadati sul server di metadati GKE. Il server di metadati GKE è un sottoinsieme degli endpoint Compute Engine server necessari per i carichi di lavoro Kubernetes.

Il server metadati GKE viene eseguito come DaemonSet, con un pod su ogni nodo Linux o servizio Windows nativo su ogni nodo di Windows nel cluster. Il server di metadati intercetta le richieste HTTP a http://metadata.google.internal (169.254.169.254:80). Ad esempio, la richiesta GET /computeMetadata/v1/instance/service-accounts/default/token recupera un token per l'account di servizio IAM che il pod è configurato per il furto d'identità. Il traffico verso il server dei metadati GKE non lascia mai l'istanza VM che ospita il pod.

Le seguenti tabelle descrivono il sottoinsieme degli endpoint del server di metadati Compute Engine disponibili con il server di metadati GKE. Per un elenco completo degli endpoint disponibili nel server dei metadati di Compute Engine, consulta Valori predefiniti delle VM VM.

Metadati dell'istanza

I metadati dell'istanza sono memorizzati nella seguente directory.

http://metadata.google.internal/computeMetadata/v1/instance/

Entry Descrizione
hostname

Il nome host del nodo.

id

L'ID univoco del nodo.

service-accounts/

Una directory di account di servizio associati al nodo. Per ogni account di servizio sono disponibili le seguenti informazioni:

  • aliases
  • email: l'indirizzo email dell'account di servizio.
  • identity: un token web JSON (JWT) univoco per il nodo. Devi includere il parametro audience nella richiesta. Ad esempio: ?audience=http://www.example.com.
  • scopes: gli ambiti di accesso assegnati all'account di servizio.
  • token: il token di accesso OAuth 2.0 per autenticare i carichi di lavoro.
zone

La zona di Compute Engine del tuo nodo GKE.

Attributi istanza

Gli attributi dell'istanza sono memorizzati nella directory seguente.

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

Entry Descrizione
cluster-location

La zona o l'area geografica di Compute Engine del tuo cluster.

cluster-name

Il nome del tuo cluster GKE.

cluster-uid

L'UID del tuo cluster GKE.

Metadati del progetto

I metadati di progetto del cluster sono archiviati nella directory seguente.

http://metadata.google.internal/computeMetadata/v1/project/

Entry Descrizione
project-id

Il tuo ID progetto Google Cloud.

numeric-project-id

Il numero del tuo progetto Google Cloud.

Alternative a Workload Identity

Puoi utilizzare una delle seguenti alternative a Workload Identity per accedere alle API Google Cloud da GKE.

  • Esporta le chiavi degli account di servizio e archiviale come secret di Kubernetes. Le chiavi degli account di servizio Google non hanno scadenza e richiedono la rotazione manuale. L'esportazione delle chiavi dell'account di servizio potrebbe ampliare l'ambito di una violazione della sicurezza se non viene rilevata. In caso di furto di una chiave esportata, un utente malintenzionato può utilizzarla per eseguire l'autenticazione come account di servizio finché non la noti e revochi manualmente la chiave.

  • Utilizza l'account di servizio predefinito di Compute Engine dei nodi. Puoi eseguire i pool di nodi come qualsiasi account di servizio IAM nel progetto. Se non specifichi un account di servizio durante la creazione del pool di nodi, GKE utilizza l'account di servizio predefinito di Compute Engine per il progetto. L'account di servizio Compute Engine è condiviso da tutti i carichi di lavoro di cui è stato eseguito il deployment su quel nodo. Ciò può causare un provisioning eccessivo delle autorizzazioni, che viola il principio del privilegio minimo ed è inappropriato per i cluster multi-tenant.

Passaggi successivi