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

Si applica a: ✔️ Servizio Azure Kubernetes Standard automatico ✔️ Servizio Azure Kubernetes standard

AKS utilizza l'identità in cinque scenari distinti. Ogni scenario risponde a una domanda diversa e ha un proprio modello di configurazione.

Per la maggior parte dei carichi di lavoro AKS di produzione, AKS Automatic è l'opzione predefinita consigliata perché si basa su una baseline di piattaforma pronta per la produzione, comprese le impostazioni predefinite relative all'identità, pur mantenendo lo stesso modello di identità di AKS descritto in questo articolo.

Questo articolo fornisce una breve introduzione di ogni scenario, spiega come le indicazioni si applicano ad AKS Automatic e AKS Standard e rimanda alla documentazione di approfondimento.

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 ID dei carichi di lavoro di Microsoft Entra

Postura delle identità nel servizio Azure Kubernetes automatico e nel servizio Azure Kubernetes standard

I cinque scenari di identità in questo articolo si applicano sia al servizio Azure Kubernetes automatico che allo standard del servizio Azure Kubernetes. La differenza principale è la postura operativa:

  • AKS Automatic offre più impostazioni predefinite preconfigurate per l'identità e la sicurezza.
  • AKS Standard offre maggiore controllo manuale e richiede più scelte di configurazione.

Usare Il servizio Azure Kubernetes Automatico come punto di partenza predefinito per la maggior parte dei carichi di lavoro di produzione e usare il servizio Azure Kubernetes Standard quando è necessaria una configurazione della piattaforma personalizzata più approfondita.

Per una panoramica di AKS Automatic, vedi Introduzione ad Servizio Azure Kubernetes (AKS) Automatic.

Confronto della gestione delle identità tra AKS Automatic e AKS Standard

Area delle identità Postura automatica di AKS Configurazione standard di AKS Ulteriori informazioni
Autenticazione dell'API Kubernetes Impostazioni predefinite orientate alla produzione con integrazione Microsoft Entra come modello consigliato Configurabile, inclusi gli account locali e le scelte di integrazione di Entra Concetti relativi all'autenticazione del cluster
Autorizzazione dell'API Kubernetes RBAC di Azure per l'autorizzazione di Kubernetes è preconfigurato Modello di autorizzazione con priorità all'account locale selezionato dalla configurazione del cluster Concetti relativi all'autorizzazione del cluster
Autorizzazione delle risorse di AKS Usa il modello Azure RBAC standard nelle operazioni sulle risorse in AKS Usa il modello Azure RBAC standard per le operazioni sulle risorse di AKS Controllo dell'accesso a kubeconfig
Identità del cluster Usa il modello di identità gestita con i valori predefiniti della configurazione di base di produzione Usa il modello di identità gestita con la configurazione selezionata dall'operatore Identità gestite in AKS
Identità del carico di lavoro L'identità del workload e l'emittente OIDC sono preconfigurati Facoltativo e configurato dall'operatore Informazioni generali sull'identità del carico di lavoro

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 Entra ID identità e gruppi per accedere al cluster. L'integrazione di Microsoft Entra effettua il provisioning e ruota l'integrazione per conto dell'utente corrente. Per abilitare, vedere Usare l'integrazione di Microsoft Entra.
  • Account locali: un certificato predefinito di amministratore del cluster 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 la maggior parte dei carichi di lavoro di produzione, inizia con AKS Automatic e l'integrazione con Microsoft Entra.

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: il modello nativo di Kubernetes Role, ClusterRole e RoleBinding valutato dal server API. Le autorizzazioni esistono nel cluster come oggetti Kubernetes.
  • Autorizzazione di Microsoft Entra ID: un webhook di autorizzazione di AKS delega le decisioni di autorizzazione a Microsoft Entra ID usando 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. Gestire le autorizzazioni centralmente in Microsoft Entra ID per gestire molti cluster da un'assegnazione di ruolo singola nell'ambito della sottoscrizione, del gruppo di gestione o del gruppo di risorse.

In AKS Automatic, Azure RBAC per l'autorizzazione di Kubernetes è preconfigurato come parte della configurazione predefinita pronta per la produzione.

Per un confronto 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 kubeconfig di un cluster, ossia un'operazione autonoma di Gestione risorse di Azure, che può essere gestita in modo granulare con il controllo degli accessi in base al ruolo di Azure. Questa operazione utilizza il RBAC di Azure standard con il provider di risorse Microsoft.ContainerService, ed è separata dall'autorizzazione dell'API di Kubernetes e si applica allo stesso modo ad AKS Automatic e ad AKS Standard. Per altre informazioni, vedere Limitare l'accesso al file di configurazione del cluster e ai ruoli predefiniti in Azure ruoli predefiniti.

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 Registro Azure Container. Le identità principali sono:

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

AKS Automatic mantiene lo stesso modello di identità, riducendo al contempo la complessità di configurazione grazie a configurazioni predefinite pronte per la produzione.

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 Azure Kubernetes utilizza l'ID del carico di lavoro di Microsoft Entra, che utilizza un token dell'account del servizio Kubernetes federato a un'applicazione di Microsoft Entra o un'identità gestita assegnata dall'utente.

Il servizio Azure Kubernetes automatico include l'identità del carico di lavoro e l'emittente OIDC come valori predefiniti già configurati. In AKS Standard queste funzionalità sono facoltative e configurate dall'operatore .

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

Guida alle decisioni

Obiettivo Usare questi documenti
Iniziare con una baseline di identità pronta per la produzione per la maggior parte dei carichi di lavoro Introduzione ad AKS Automatic
Concedere l'accesso 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
Autore delle autorizzazioni per cluster e per spazio dei nomi come oggetti Kubernetes Usare RBAC di Kubernetes con l'integrazione di Entra
Consentire al cluster di eseguire il pull dal Registro Azure Container o collegare i dischi. Identità gestite in AKS
Consentire ai pod di accedere a Key Vault o Archiviazione senza usare segreti. Panoramica di ID dei carichi di lavoro di Microsoft Entra
Limitare chi può scaricare il cluster kubeconfig Limitare l'accesso al file di configurazione del cluster
Creare un cluster pronto per la produzione con il comportamento di identità predefinito Creare un cluster automatico di AKS

Riferimento alle autorizzazioni del servizio AKS

Per le autorizzazioni Azure usate dal servizio Azure Kubernetes (l'identità che crea il cluster, l'identità del cluster in fase di esecuzione, le autorizzazioni aggiuntive per l'identità del cluster e l'accesso al nodo del servizio Azure Kubernetes), vedere Informazioni di riferimento sulle autorizzazioni del servizio Azure Kubernetes.

Contenuti correlati

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

  • Last updated on