Concetti relativi all'autenticazione del cluster nel servizio Azure Kubernetes

Questo articolo descrive in che modo il servizio Azure Kubernetes autentica i chiamanti all'API Kubernetes, ovvero chi può connettersi al piano di controllo. Illustra il percorso di autenticazione consigliato basato su ID di Microsoft Entra e come bloccare l'accesso break-glass.

Per informazioni su come Azure Kubernetes Service (AKS) valuta ciò che un chiamante autenticato è autorizzato a fare, vedere Concetti relativi all'autorizzazione del cluster.

Per gli altri scenari di identità in Azure Kubernetes Service, consultare:

Per un orientamento in tutti e quattro gli scenari di identità del servizio Azure Kubernetes, vedere Opzioni di accesso e identità per il servizio Azure Kubernetes.

Eseguire l'autenticazione nel server API Kubernetes (piano di controllo)

Kubernetes di per sé non fornisce una directory di identità. Senza un provider di identità esterno, è necessario gestire le credenziali locali per ogni cluster, il che non è scalabile e crea lacune di audit.

È consigliabile distribuire i cluster AKS con l'autenticazione con Microsoft Entra ID per il piano di controllo. Con questa integrazione, il cluster convalida le richieste API Kubernetes in ingresso rispetto all'ID Microsoft Entra e usa l'identità Entra del chiamante per le decisioni di autorizzazione. Microsoft Entra ID centralizza il livello di identità, ovvero qualsiasi modifica dello stato dell'utente o del gruppo si riflette automaticamente nell'accesso al cluster e abilita l'accesso condizionale, l'autenticazione a più fattori e Privileged Identity Management.

Diagramma che mostra l'integrazione di Microsoft Entra con i cluster del servizio Azure Kubernetes per l'autenticazione.

Per la configurazione, vedere Abilitare l'autenticazione Microsoft Entra ID per il control plane di AKS. Nota quanto segue:

  • ** Il tenant di Microsoft Entra configurato per l'autenticazione del cluster deve essere uguale al tenant dell'abbonamento che ospita il cluster AKS.
  • Per l'accesso non interattivo o le versioni precedenti di kubectl, utilizzare il plugin kubelogin.

Provider di identità esterni (anteprima)

Alcune organizzazioni devono autenticare gli utenti del cluster con un provider di identità conforme a OIDC diverso da Microsoft Entra ID, ad esempio GitHub, Google Workspace, Okta o un IdP self-hosted. AKS supporta questa funzionalità tramite l'autenticazione strutturata, che configura i JWT autenticatori del server API Kubernetes per convalidare i token rilasciati dal tuo provider esterno.

Usare questa opzione solo quando si ha un requisito rigido per mantenere l'identità del cluster all'esterno dell'ID Microsoft Entra. In caso contrario, preferisce il percorso ID Microsoft Entra per un'integrazione più completa con l'accesso condizionale, l'autenticazione a più fattori e Privileged Identity Management.

Per una panoramica, vedere Autenticazione del provider di identità esterna per i cluster AKS. Per la configurazione, vedere Configurare provider di identità esterni con AKS structured authentication.

Disabilitare gli account locali

Gli account locali usano un certificato amministratore del cluster predefinito che ignora l'ID Microsoft Entra. Qualsiasi chiamante che può elencare queste credenziali ottiene l'accesso completo dell'amministratore del cluster senza passare attraverso Entra ID, che interrompe il controllo centralizzato, l'accesso condizionale e Privileged Identity Management. Nell'ambiente di produzione, disabilitare gli account locali in modo che tutti gli accessi passino attraverso Microsoft Entra ID.

Per applicare questa funzionalità su larga scala in molti cluster, assegnare la politica predefinita di Azure I cluster del servizio Azure Kubernetes dovrebbero avere i metodi di autenticazione locale disabilitati a un ambito di sottoscrizione o di gruppo di gestione. Le policy verificano o rifiutano i cluster creati o aggiornati con account locali abilitati. Per l'elenco completo dei criteri predefiniti del servizio Azure Kubernetes, vedere Definizioni predefinite di Criteri di Azure per il servizio Azure Kubernetes.

Per informazioni dettagliate, vedere Gestire gli account locali nel servizio Azure Kubernetes.

Eseguire l'autenticazione nei nodi del cluster

Modalità di accesso SSH

Oltre all'autenticazione all'API Kubernetes, potrebbe anche essere necessario eseguire l'autenticazione direttamente in un nodo tramite SSH per la risoluzione dei problemi. Il servizio Azure Kubernetes supporta tre modalità di accesso SSH impostate per ogni cluster o pool di nodi:

  • Ssh disabilitato (anteprima): bloccare completamente l'accesso SSH ai nodi. Consigliato per la produzione in cui l'accesso a livello di nodo viene regolato solo tramite kubectl debug o altri percorsi nativi di Kubernetes.
  • Microsoft Entra ID basato su SSH (anteprima): accedere ai nodi usando le identità di Microsoft Entra, senza chiavi SSH da gestire. Questa modalità è coerente con il resto dell'autenticazione del cluster: eredita l'accesso condizionale e l'autenticazione a più fattori da Entra ID, supporta l'elevazione just-in-time tramite il controllo degli accessi in base al ruolo di Azure e la gestione delle identità privilegiate e centralizza la verifica tramite i log di accesso di Entra ID.
  • SSH utente locale: accesso tradizionale basato su chiavi SSH. Usare questa opzione solo quando SSH basato su Entra ID non è un'opzione e ruotare regolarmente le chiavi.

Per i passaggi di configurazione e per modalità, vedere Gestire l'accesso SSH nei nodi del cluster del servizio Azure Kubernetes.

Passaggi successivi

  • Last updated on