Vincoli di identità per Servizio Azure Kubernetes (AKS) (anteprima)

L'associazione di identità è una funzionalità di anteprima per il servizio Azure Kubernetes che estende la funzionalità di identità dei carichi di lavoro esistente per risolvere le limitazioni di scalabilità delle credenziali di identità federate nelle identità gestite assegnate dall'utente. Con l'identità dei carichi di lavoro nel servizio Azure Kubernetes, una singola identità gestita assegnata dall'utente può avere oltre 20 credenziali di identità federate. Le distribuzioni della piattaforma Kubernetes di grandi dimensioni possono estendersi su più di 20 cluster (ogni cluster ha un'autorità emittente univoca) o avere molte <namespace, service-account> combinazioni che richiedono la mappatura alla stessa UAMI, raggiungendo il limite della quota FIC.

Le associazioni di identità rispondono a questa limitazione consentendo a più cluster del servizio Azure Kubernetes di condividere la stessa identità gestita assegnata dall'utente usando una singola credenziale di identità federata per identità gestita. Questo approccio aumenta significativamente la scalabilità e semplifica le operazioni per ambienti del servizio Azure Kubernetes su larga scala che richiedono l'autenticazione di Microsoft Entra.

Che cos'è un'associazione di identità?

Un'associazione di identità è un mapping di risorse tra un UAMI e un cluster AKS con carichi di lavoro che richiedono l'autenticazione di Microsoft Entra con tale identità.

Si supponga di avere un UAMI, MI-1, necessario per i carichi di lavoro in esecuzione nei cluster AKS-cluster-1, AKS-cluster-2e AKS-cluster-3. È possibile creare tre associazioni di identità per eseguire il mapping MI-1 a ciascuno di questi cluster:

• Associazione di identità IB-A mapping MI-1 a AKS-cluster-1.
• Associazione di identità IB-B mapping MI-1 a AKS-cluster-2.
• Associazione di identità IB-C mapping MI-1 a AKS-cluster-3.

Anche se lo stesso UAMI è necessario in più cluster, viene creata una sola credenziale di identità federata per ogni UAMI, risolvendo la precedente limitazione di 20 FIC. Quando si crea un'associazione di identità, il servizio Azure Kubernetes crea automaticamente (o riutilizza) l'unica credenziale di identità federata per l'identità gestita assegnata dall'utente specifica. I diagrammi seguenti illustrano le differenze tra il modello di identità del carico di lavoro precedente e il nuovo modello di associazioni di identità:

Dopo aver creato l'associazione di identità e l'UAMI è autorizzato per il cluster, è necessario definire ClusterRole e ClusterRoleBinding oggetti che specificano gli spazi dei nomi e gli account di servizio (in modo granulare o collettivo) autorizzati a usare tale identità gestita per l'acquisizione del token Microsoft Entra.

Usare le associazioni di identità con le librerie client di Azure Identity

Per usare le associazioni di identità con i carichi di lavoro dell'applicazione, seguire questa procedura:

1. Assicurarsi di usare il pacchetto di identità di Azure minimo necessario.
2. Usare WorkloadIdentityCredential e acconsentire esplicitamente alla funzionalità. Questa funzionalità non è supportata in ManagedIdentityCredential o DefaultAzureCredential.

La tabella seguente illustra le versioni minime dei pacchetti e come abilitare le associazioni di identità per ogni lingua supportata:

Domande frequenti

La stessa identità (spazio dei nomi e account del servizio) è necessaria per i cluster che usano lo stesso UAMI?

No. Le associazioni di identità non richiedono la corrispondenza tra spazio dei nomi e account del servizio. Spetta all'operatore del cluster concedere esplicitamente l'autorizzazione ai namespace e ai service account all'interno di ogni cluster che possono utilizzare la managed identity attraverso il controllo degli accessi basato sui ruoli (RBAC).

È possibile creare più associazioni di identità per lo stesso UAMI?

Sì. L'URL dell'emittente OIDC mantenuto dal servizio Azure Kubernetes per quella UAMI è lo stesso in tutti i binding di identità che fanno riferimento alla stessa identità gestita.

Quali autorizzazioni sono necessarie per creare associazioni di identità?

Autorizzazioni di Azure Resource Manager (ARM) necessarie:

• Microsoft.ContainerService/managedClusters/identityBindings/*
• Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/*

Autorizzazioni Kubernetes necessarie:

• Possibilità di creare oggetti ClusterRole e ClusterRoleBinding (amministratore del cluster o equivalente).

Cosa accade al FIC creato automaticamente dopo l'eliminazione di tutte le associazioni di identità per un UAMI?

Attualmente non è presente alcuna GC automatica del FIC quando viene eliminata l'ultimo binding di identità che fa riferimento a un UAMI. Gli operatori devono eseguire manualmente la pulizia del FIC solo dopo aver verificato che tutti i legami d'identità per tale UAMI siano stati rimossi per evitare di compromettere le dipendenze residue.

Quali prerequisiti di rete esistono per le associazioni di identità?

In precedenza, l'identità del carico di lavoro richiedeva dati in uscita verso login.microsoftonline.com per consentire ai carichi di lavoro di scambiare i token degli account del servizio con i token di accesso di Microsoft Entra. Con i binding di identità, le richieste di scambio di token vengono instradate tramite un proxy di binding di identità specifico del cluster gestito dal servizio Azure Kubernetes. L'uscita diretta a login.microsoftonline.com per lo scambio di token non è necessaria.

Quali limitazioni esistono per i vincoli di identità?

Le associazioni di identità non sono ancora supportate nei cluster configurati con l'integrazione della rete virtuale del server API.

Contenuti correlati

• Configurare le associazioni di identità per il servizio Azure Kubernetes