Opzioni di accesso e identità per Azure Kubernetes Service (AKS)

AKS utilizza l'identità in cinque scenari distinti. Ogni scenario risponde a una domanda diversa e ha un proprio modello di configurazione. Questo articolo offre una breve introduzione a ogni documento e punta alla documentazione approfondita.

Cinque scenari di identità in AKS

Scenario Domanda a cui risponde Documentazione approfondita
R. Autenticazione del piano di controllo Kubernetes Chi è il chiamante che raggiunge l'API Kubernetes? Concetti relativi all'autenticazione del cluster, provider di identità esterni
B. Autorizzazione del piano di controllo Kubernetes Che cosa può fare il chiamante dopo l'autenticazione all'API Kubernetes? Concetti relativi all'autorizzazione del cluster
C. Autorizzazione delle risorse AKS (Azure Resource Manager) Chi può eseguire operazioni a livello di Azure sulla risorsa AKS, ad esempio eseguire un pull kubeconfig? Limitare l'accesso al file di configurazione del cluster, ruoli predefiniti di Azure
D. Identità del cluster (cluster → Azure) In che modo il cluster AKS opera su Azure per gestire le risorse per conto dell'utente? Identità gestite in AKS
E. Identità del carico di lavoro (pod → Azure) In che modo i pod eseguono l'autenticazione ai servizi di Azure, ad esempio Key Vault o Archiviazione? Panoramica di Microsoft Entra Workload ID

Il resto di questo articolo fornisce un breve orientamento a ogni scenario.

R. Autenticazione del piano di controllo kubernetes

L'autenticazione del piano di controllo Kubernetes stabilisce l'identità di un utente o di un'entità servizio che chiama il server API Kubernetes. AKS supporta:

  • Microsoft Entra ID (scelta consigliata). Usare le identità e i gruppi di Entra ID per autenticarsi nel cluster. L'integrazione di Microsoft Entra effettua il provisioning e ruota l'integrazione per conto dell'utente. Per abilitare, vedere Usare l'integrazione di Microsoft Entra.
  • Account locali. Certificato di amministratore del cluster integrato che ignora Entra ID. È consigliabile disabilitare gli account locali nell'ambiente di produzione. Vedere Gestire gli account locali.
  • Provider di identità esterni. Usare un provider di identità conforme a OIDC diverso da Microsoft Entra ID. Vedere Autenticazione del provider di identità esterno.

Per informazioni approfondite sul modo in cui il servizio Azure Kubernetes autentica le richieste api Kubernetes, vedere Concetti relativi all'autenticazione del cluster.

B. Autorizzazione del piano di controllo Kubernetes

Dopo che un chiamante è stato autenticato nell'API Kubernetes, Azure Kubernetes Service (AKS) autorizza la richiesta usando uno o entrambi i due modelli:

  • Kubernetes RBAC (Controllo degli accessi in base al ruolo) Il modello Kubernetes Role / ClusterRole / RoleBinding nativo valutato dal server API. Le autorizzazioni esistono nel cluster come oggetti Kubernetes.
  • Autorizzazione dell'ID Microsoft Entra. Un webhook di autorizzazione di Azure Kubernetes Service delega le decisioni di autorizzazione a Microsoft Entra ID utilizzando le assegnazioni di ruolo di Azure. Le assegnazioni di ruolo RBAC di Azure con dataActions sono supportate per tutte le risorse API standard di Kubernetes, e le assegnazioni di ruolo con condizioni ABAC di Azure sono supportate per le risorse personalizzate. Le autorizzazioni vengono gestite centralmente in Microsoft Entra ID e possono gestire molti cluster da un'assegnazione di ruolo singola nell'ambito della sottoscrizione, del gruppo di gestione o del gruppo di risorse.

Per un confronto side-by-side e indicazioni su quando usare ogni modello, vedere Concetti relativi all'autorizzazione del cluster.

C. Autorizzazione delle risorse AKS (Azure Resource Manager)

Oltre a autorizzare le chiamate all'API Kubernetes, è anche necessario autorizzare le operazioni a livello Azure sulla risorsa AKS stessa. L'esempio più comune è controllare chi può eseguire il pull di un cluster, ovvero un'operazione autonoma di Azure Resource Manager che è possibile gestire in modo granulare con il controllo degli accessi in base al ruolo di kubeconfigAzure. Si tratta di Azure RBAC standard per il provider di risorse Microsoft.ContainerService, separato dall'autorizzazione dell'API Kubernetes. Vedere Limitare l'accesso al file di configurazione del cluster e ai ruoli predefiniti nei ruoli predefiniti di Azure.

D. Identità del cluster (cluster → Azure)

I cluster AKS (Azure Kubernetes Service) usano le identità gestite di Azure per agire per conto dell'utente, ad esempio per creare servizi di bilanciamento del carico, collegare dischi o scaricare immagini da Azure Container Registry. Le identità principali sono:

  • Identità del piano di controllo. Usato dal piano di controllo del cluster per gestire le risorse di Azure per il cluster.
  • Identità Kubelet. Usato da kubelet in ogni nodo per eseguire l'autenticazione a servizi come Registro Azure Container.
  • Identità dei componenti aggiuntivi/estensioni. Alcuni componenti aggiuntivi ed estensioni di AKS usano le proprie identità gestite.

Per informazioni dettagliate su ogni tipo di identità e su come usare identità assegnate dal sistema e assegnate dall'utente, vedere Identità gestite nel servizio Azure Kubernetes.

E. Identità del carico di lavoro (pod → Azure)

L'identità del carico di lavoro consente ai pod in esecuzione nel tuo cluster AKS di autenticarsi ai servizi di Azure protetti da Microsoft Entra (come Key Vault, Storage o Cosmos DB) senza memorizzare segreti nel cluster. Il servizio AKS (Azure Kubernetes Service) utilizza l'ID di carico di lavoro Microsoft Entra, che sfrutta un token dell'account di servizio Kubernetes federato a un'applicazione Microsoft Entra o a un'identità gestita assegnata dall'utente.

Non usare l'identità deprecata gestita da pod di Microsoft Entra per i nuovi carichi di lavoro.

Guida alle decisioni

Obiettivo Usare questi documenti
Accedere agli utenti nel cluster con Microsoft Entra ID Abilitare l'integrazione di Microsoft Entra
Gestire chi può eseguire le operazioni nell'API Kubernetes in molti cluster Usare l'autorizzazione microsoft Entra ID per l'API Kubernetes
Limitare l'accesso a tipi di risorse personalizzati specifici Condizioni ABAC nell'autorizzazione Entra ID
Autorizzare permessi per-cluster e per-namespace come oggetti Kubernetes Usare RBAC di Kubernetes con l'integrazione di Entra
Consentire al cluster di prelevare dal Registro Azure Container (ACR) o di collegare dischi. Identità gestite in AKS
Consentire ai pod di accedere a Key Vault o Archiviazione senza usare segreti. Panoramica di Microsoft Entra Workload ID
Limitare chi può scaricare il cluster kubeconfig Limitare l'accesso al file di configurazione del cluster

Riferimento alle autorizzazioni del servizio AKS

Per le autorizzazioni di Azure usate dal servizio Azure Kubernetes, ovvero l'identità del cluster, l'identità del cluster in fase di esecuzione, le autorizzazioni aggiuntive per l'identità del cluster e l'accesso ai nodi del servizio Azure Kubernetes, vedere Informazioni di riferimento sulle autorizzazioni del servizio Azure Kubernetes.

Passaggi successivi

Per ulteriori informazioni sui concetti principali di Kubernetes e AKS, consultare i seguenti articoli:

  • Last updated on