Usare l'ID del carico di lavoro Microsoft Entra con il servizio Azure Kubernetes

I carichi di lavoro distribuiti in un cluster dei servizi Azure Kubernetes richiedono credenziali dell'applicazione Microsoft Entra o identità gestite per accedere alle risorse protette di Microsoft Entra, ad esempio Azure Key Vault e Microsoft Graph. Microsoft Entra Workload ID si integra con le funzionalità native di Kubernetes per la federazione con provider di identità esterni.

L'ID dei carichi di lavoro di Microsoft Entra usa proiezione del volume del token dell'account del servizio (ovvero, un account del servizio), per consentire ai pod di usare un'identità Kubernetes. Viene rilasciato un token Kubernetes e la federazione OIDC consente alle applicazioni Kubernetes di accedere in modo sicuro alle risorse di Azure con Microsoft Entra ID in base agli account del servizio con annotazioni.

L'ID dei carichi di lavoro di Microsoft Entra funziona particolarmente bene con le librerie client di Identità di Azure o la raccolta di Microsoft Authentication Library (MSAL), insieme alla registrazione dell'applicazione. Il carico di lavoro può usare una di queste librerie per autenticare e accedere facilmente alle risorse cloud di Azure.

Questo articolo illustra gli ID dei carichi di lavoro di Microsoft Entra ed esamina le opzioni disponibili per pianificare la strategia del progetto e la potenziale migrazione dall'identità gestita dai pod di Microsoft Entra.

Nota

È possibile usare Connettore di servizi per configurare automaticamente alcuni passaggi. Vedere anche: Che cos'è Connettore di servizi?

Dipendenze

  • Il servizio Azure Kubernetes supporta l'ID del carico di lavoro Microsoft Entra nella versione 1.22 e successive.
  • Interfaccia della riga di comando di Azure versione 2.47.0 o successiva. Eseguire az --version per trovare la versione ed eseguire az upgrade per aggiornare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

Librerie client di Identità di Azure

Nelle librerie client di Identità di Azure scegliere uno degli approcci seguenti:

  • Usare DefaultAzureCredential, che tenta di usare WorkloadIdentityCredential.
  • Creare un'istanza ChainedTokenCredential che include WorkloadIdentityCredential.
  • Usare direttamente WorkloadIdentityCredential.

La tabella seguente fornisce la versione minima del pacchetto necessaria per la libreria client di ogni ecosistema di lingue.

Ecosistema Libreria Versione minima
.NET Azure.Identity 1.9.0
C++ azure-identity-cpp 1.6.0
Go azidentity 1.3.0
Java azure-identity 1.9.0
Node.js @azure/identity 3.2.0
Python azure-identity 1.13.0

Negli esempi di codice seguenti viene usato DefaultAzureCredential. Questo tipo di credenziale usa le variabili di ambiente inserite dal webhook di modifica dell'identità del carico di lavoro di Azure per l'autenticazione con Azure Key Vault.

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

string keyVaultUrl = Environment.GetEnvironmentVariable("KEYVAULT_URL");
string secretName = Environment.GetEnvironmentVariable("SECRET_NAME");

var client = new SecretClient(
    new Uri(keyVaultUrl),
    new DefaultAzureCredential());

KeyVaultSecret secret = await client.GetSecretAsync(secretName);

Microsoft Authentication Library (MSAL)

Le librerie client seguenti sono la versione minima richiesta.

Ecosistema Libreria Image Esempio Dispone di Windows
.NET Microsoft Authentication Library-for-dotnet ghcr.io/azure/azure-workload-identity/msal-net:latest Collegamento
Go Microsoft Authentication Library-for-go ghcr.io/azure/azure-workload-identity/msal-go:latest Collegamento
Java Microsoft Authentication Library-for-java ghcr.io/azure/azure-workload-identity/msal-java:latest Collegamento No
JavaScript Microsoft Authentication Library-for-js ghcr.io/azure/azure-workload-identity/msal-node:latest Collegamento No
Python Microsoft Authentication Library-for-python ghcr.io/azure/azure-workload-identity/msal-python:latest Collegamento No

Limiti

  • È possibile disporre di massimo 20 credenziali di identità federate per ogni identità gestita.
  • La propagazione delle credenziali di identità federata dopo l'aggiunta iniziale richiede alcuni secondi.
  • I nodi virtuali aggiunti, in base al progetto open source Virtual Kubelet, non sono supportati.
  • La creazione di credenziali di identità federate non è supportata nelle identità gestite assegnate dall'utente in queste aree.

Funzionamento

In questo modello di sicurezza il cluster del servizio Azure Kubernetes funge da emittente del token. Microsoft Entra ID usa OpenID Connect per individuare le chiavi di firma pubbliche e verificare l'autenticità del token dell'account del servizio prima di scambiarlo per un token Microsoft Entra. Il carico di lavoro può scambiare un token dell'account del servizio proiettato nel volume per un token Microsoft Entra usando la libreria client di Identità di Azure o Microsoft Authentication Library (MSAL).

Diagramma del modello di sicurezza delle identità del carico di lavoro del servizio Azure Kubernetes.

La tabella seguente descrive gli endpoint dell'autorità emittente OIDC necessari per l'ID del carico di lavoro Microsoft Entra:

Endpoint Descrizione
{IssuerURL}/.well-known/openid-configuration Noto anche come documento di individuazione OIDC. Contiene i metadati relativi alle configurazioni dell'autorità emittente.
{IssuerURL}/openid/v1/jwks Contiene le chiavi di firma pubbliche usate da Microsoft Entra ID per verificare l'autenticità del token dell'account del servizio.

Il diagramma seguente riepiloga la sequenza di autenticazione usando OpenID Connect.

Diagramma della sequenza di autenticazione OIDC dell'identità del carico di lavoro del servizio Azure Kubernetes.

Rotazione automatica del certificato webhook

Analogamente ad altri componenti aggiuntivi webhook, il certificato viene ruotato dall'operazione di rotazione automatica del certificato del cluster.

Etichette e annotazioni dell'account del servizio

Microsoft Entra Workload ID supporta i mapping seguenti correlati a un account del servizio:

  • Uno-a-uno, in cui un account di servizio fa riferimento a un oggetto Microsoft Entra.
  • Molti-a-uno, in cui più account di servizio fanno riferimento allo stesso oggetto Microsoft Entra.
  • Uno-a-molti, in cui un account del servizio fa riferimento a più oggetti Microsoft Entra modificando l'annotazione ID client. Per altre informazioni, vedere Come eseguire la federazione di più identità con un account del servizio Kubernetes.

Nota

Se le annotazioni dell'account del servizio vengono aggiornate, è necessario riavviare il pod per rendere effettive le modifiche.

Se è stata usata l’identità gestita da pod di Microsoft Entra, si consideri un account del servizio come un'entità di sicurezza di Azure, ad eccezione di un account del servizio fa parte dell'API Kubernetes di base, anziché una definizione di risorsa personalizzata (CRD). Nella seguente sezione viene descritto un elenco di etichette e annotazioni disponibili che possono essere usate per configurare il comportamento durante lo scambio del token dell'account del servizio per un token di accesso Microsoft Entra.

Annotazioni dell'account del servizio

Tutte le annotazioni sono facoltative. Se l'annotazione non è specificata, verrà usato il valore predefinito.

Annotazione Descrizione Default
azure.workload.identity/client-id Rappresenta l'applicazione Microsoft Entra
ID client da usare con il pod.
azure.workload.identity/tenant-id Rappresenta l'ID tenant di Azure in cui
l'applicazione Microsoft Entra è registrata.
Variabile di ambiente AZURE_TENANT_ID estratta
da azure-wi-webhook-config ConfigMap.
azure.workload.identity/service-account-token-expiration Rappresenta il campo expirationSeconds per l'oggetto
token dell'account del servizio proiettato. Si tratta di un campo facoltativo configurato per evitare tempi di inattività
causato da errori durante l'aggiornamento del token dell'account del servizio. La scadenza del token dell'account del servizio Kubernetes non è correlata ai token di Microsoft Entra. I token di Microsoft Entra scadono entro 24 ore dall'emissione.
3600
L'intervallo supportato è 3600-86400.

Etichette dei pod

Nota

Per le applicazioni che usano l'identità del carico di lavoro, è necessario aggiungere l'etichetta azure.workload.identity/use: "true" alla specifica del pod per il servizio Azure Kubernetes per spostare l'identità del carico di lavoro in uno scenario di chiusura non riuscita per fornire un comportamento coerente e affidabile per i pod che devono usare l'identità del carico di lavoro. In caso contrario, i pod avranno esito negativo dopo il riavvio.

Etichetta Descrizione Valore consigliato Richiesto
azure.workload.identity/use Questa etichetta è necessaria nella specifica del modello di pod. Solo i pod con questa etichetta vengono modificati dal webhook azure-workload-identity che modifica l'ammissione per inserire le variabili di ambiente specifiche di Azure e il volume del token dell'account del servizio proiettato. true

Annotazioni dei pod

Tutte le annotazioni sono facoltative. Se l'annotazione non è specificata, verrà usato il valore predefinito.

Annotazione Descrizione Default
azure.workload.identity/service-account-token-expiration Rappresenta il campo expirationSeconds per il token dell'account del servizio proiettato. Si tratta di un campo facoltativo configurato per evitare tempi di inattività causati da errori durante l'aggiornamento del token dell'account del servizio. La scadenza del token dell'account del servizio Kubernetes non è correlata ai token di Microsoft Entra. I token di Microsoft Entra scadono entro 24 ore dall'emissione. 1 3600
L'intervallo supportato è 3600-86400.
azure.workload.identity/skip-containers Rappresenta un elenco delimitato da punti e virgola dei contenitori per ignorare l'aggiunta del volume di token dell'account del servizio proiettato. Ad esempio, container1;container2. Per impostazione predefinita, il volume del token dell'account del servizio proiettato viene aggiunto a tutti i contenitori se l'account del servizio è etichettato con azure.workload.identity/use: true.
azure.workload.identity/inject-proxy-sidecar Inserisce un contenitore proxy init e un sidecar proxy nel pod. Il sidecar proxy viene usato per intercettare le richieste di token a IMDS e acquisire un token Microsoft Entra per conto dell'utente con credenziali di identità federate. true
azure.workload.identity/proxy-sidecar-port Rappresenta la porta del sidecar proxy. 8000

1 Ha la precedenza anche se l'account del servizio è annotato.

Come eseguire la migrazione a ID dei carichi di lavoro di Microsoft Entra

In un cluster che esegue già un'identità gestita da pod, è possibile configurarla in modo da usare l'identità del carico di lavoro uno dei due modi. La prima opzione consente di usare la stessa configurazione implementata per l'identità gestita da pod. È possibile annotare l'account del servizio all'interno dello spazio dei nomi con l'identità per abilitare ID dei carichi di lavoro di Microsoft Entra e inserire le annotazioni nei pod.

La seconda opzione consiste nel riscrivere l'applicazione per usare la versione più recente della libreria client di Azure Identity.

Per semplificare e facilitare il processo di migrazione, è stato sviluppato un sidecar di migrazione che converte le transazioni IMDS effettuate dall'applicazione in OpenID Connect (OIDC). Il sidecar della migrazione non è progettato per essere una soluzione a lungo termine, ma un modo per iniziare rapidamente a usare l'identità del carico di lavoro. L'esecuzione del sidecar di migrazione all'interno del proxy dell'applicazione esegue le transazioni IMDS dell'applicazione in OIDC. L'approccio alternativo consiste nell'eseguire l'aggiornamento a una versione supportata della libreria client di Azure Identity, che supporta l'autenticazione OIDC.

La tabella seguente riepiloga le raccomandazioni sulla migrazione o sulla distribuzione per l'identità del carico di lavoro.

Scenario Descrizione
La distribuzione di cluster nuova o esistente esegue una versione supportata della libreria client di Identità di Azure Non sono necessari passaggi di migrazione.
Risorse di distribuzione di esempio: distribuire e configurare l'identità del carico di lavoro in un nuovo cluster
La distribuzione di cluster nuovi o esistenti esegue una versione non supportata della libreria client di Identità di Azure Aggiornare l'immagine del contenitore per usare una versione supportata di Azure Identity SDK o usare il sidecar di migrazione.

Passaggi successivi