Opzioni di accesso e identità per il servizio Azure Kubernetes

Articolo
08/06/2024

Puoi autenticare, autorizzare, proteggere e controllare l'accesso ai cluster Kubernetes in diversi modi:

Usando il controllo degli accessi in base al ruolo di Kubernetes (RBAC Kubernetes), puoi concedere agli utenti, ai gruppi e agli account del servizio l'accesso alle sole risorse di cui hanno bisogno.
Con il servizio Azure Kubernetes (AKS) puoi migliorare ulteriormente la struttura di sicurezza e autorizzazioni usando Microsoft Entra ID e il Controllo degli accessi in base al ruolo di Azure (RBAC).

Il controllo degli accessi in base al ruolo di Kubernetes e il servizio Azure Kubernetes ti permettono di proteggere l'accesso al tuo cluster e fornire solo le autorizzazioni minime necessarie a sviluppatori e operatori.

Questo articolo introduce i principali concetti utili per l'autenticazione e l'assegnazione di autorizzazioni nel servizio Azure Kubernetes.

Controllo degli accessi in base al ruolo di Kubernetes

Il controllo degli accessi in base al ruolo di Kubernetes offre un filtro granulare delle azioni utente. Con questo meccanismo di controllo:

Puoi assegnare agli utenti o ai gruppi di utenti l'autorizzazione per creare e modificare le risorse o visualizzare i log dai carichi di lavoro delle applicazioni in esecuzione.
Puoi definire l'ambito delle autorizzazioni in un singolo spazio dei nomi o nell'intero cluster del servizio Azure Kubernetes.
Puoi creare ruoli per definire le autorizzazioni e poi assegnare questi ruoli agli utenti con le associazioni dei ruoli.

Per ulteriori informazioni, vedi Uso dell'autorizzazione del controllo degli accessi in base al ruolo di Kubernetes.

Role e ClusterRole

ruoli

Prima di assegnare autorizzazioni agli utenti con il controllo degli accessi in base al ruolo di Kubernetes, definirai le autorizzazioni utente come Ruolo. Concedi le autorizzazioni all'interno di uno spazio dei nomi usando i ruoli.

Nota

I ruoli Kubernetes concedono le autorizzazioni e non negano le autorizzazioni.

Per concedere le autorizzazioni nell'intero cluster o alle risorse cluster all'esterno di un determinato spazio dei nomi, puoi invece usare i ClusterRoles.

ClusterRoles

Un ClusterRole concede e applica le autorizzazioni alle risorse nell'intero cluster, non a uno spazio dei nomi specifico.

RoleBinding e ClusterRoleBinding

Dopo aver definito i ruoli per concedere le autorizzazioni alle risorse, assegni tali autorizzazioni di controllo degli accessi in base al ruolo di Kubernetes con un RoleBinding. Se il cluster del servizio Azure Kubernetes si integra con Microsoft Entra ID, RoleBindings concede le autorizzazioni agli utenti di Microsoft Entra per eseguire azioni all'interno del cluster. Scopri come in Controllare l'accesso alle risorse del cluster usando il controllo degli accessi in base al ruolo di Kubernetes e le identità di Microsoft Entra.

RoleBindings

Assegnare ruoli agli utenti per uno spazio dei nomi specifico usando RoleBindings. Con RoleBindings puoi separare logicamente un singolo cluster del servizio Azure Kubernetes e gli utenti potranno accedere solo alle risorse dell'applicazione nello spazio dei nomi assegnato.

Per associare i ruoli nell'intero cluster, o alle risorse cluster all'esterno di un determinato spazio dei nomi, puoi invece usare i ClusterRoleBindings.

ClusterRoleBinding

Con un ClusterRoleBinding, puoi associare i ruoli agli utenti e applicare alle risorse nell'intero cluster, non a uno specifico spazio dei nomi. Questo approccio consente di concedere agli amministratori o ai tecnici del supporto l'accesso a tutte le risorse nel cluster del servizio Azure Kubernetes.

Nota

Microsoft/servizio Azure Kubernetes esegue tutte le azioni del cluster con il consenso dell'utente con un ruolo Kubernetes predefinitoaks-service e un'associazione di ruoli predefinita aks-service-rolebinding.

Questo ruolo consente al servizio Azure Kubernetes di risolvere e diagnosticare i problemi del cluster, ma non può modificare le autorizzazioni né creare ruoli o associazioni di ruoli o altre azioni con privilegi elevati. L'accesso ai ruoli è abilitato solo nei ticket di supporto attivi con accesso JIT (Just-In-Time). Scopri di più sui criteri di supporto del servizio Azure Kubernetes.

Account del servizio Kubernetes

Uno dei tipi di utenti primari in Kubernetes è account del servizio. L'API Kubernetes contiene e gestisce gli account del servizio. Le credenziali per gli account del servizio vengono archiviate come segreti di Kubernetes e possono quindi essere usate da pod autorizzati a comunicare con il server dell'API. La maggior parte delle richieste API crea un token di autenticazione per un account del servizio o un account utente normale.

Gli account utente normali consentono l'accesso più tradizionale ad amministratori o sviluppatori, non solo a servizi e processi. Sebbene Kubernetes non fornisca una soluzione di gestione delle identità per archiviare gli account utente e le password normali, puoi integrare soluzioni di gestione delle identità esterne in Kubernetes. Per i cluster del servizio Azure Kubernetes, questa soluzione di gestione delle identità integrata è Microsoft Entra ID.

Per altre informazioni sulle opzioni di gestione delle identità in Kubernetes, vedere Kubernetes authentication (Autenticazione di Kubernetes).

Controllo dell'accesso basato sui ruoli di Azure

Il controllo degli accessi in base al ruolo di Azure (RBAC) è un sistema di autorizzazione basato su Azure Resource Manager che garantisce una gestione con granularità fine degli accessi alle risorse di Azure.

Sistema RBCA (Controllo degli accessi in base al ruolo)	Descrizione
Controllo degli accessi in base al ruolo di Kubernetes	Progettato per lavorare sulle risorse Kubernetes all'interno del cluster del servizio Azure Kubernetes.
Controllo degli accessi in base al ruolo di Azure	Progettato per lavorare sulle risorse all'interno della sottoscrizione di Azure.

Con il controllo degli accessi in base al ruolo di Azure si crea una definizione del ruolo che indica le autorizzazioni da applicare. A questo punto puoi assegnare un utente o un gruppo a questa definizione di ruolo tramite un'assegnazione di ruolo per un determinato ambito. L'ambito può essere una singola risorsa, un gruppo di risorse o una sottoscrizione.

Per ulteriori informazioni, vedi Che cos'è il controllo degli accessi in base al ruolo di Azure?

Per gestire completamente un cluster del servizio Azure Kubernetes sono necessari due livelli di accesso:

Accesso alla risorsa del servizio Azure Kubernetes nella sottoscrizione di Azure.
- Controllare il ridimensionamento o l'aggiornamento del cluster usando le API del servizio Azure Kubernetes.
- Esegui il pull di kubeconfig.
Accesso all'API Kubernetes. Questo accesso è controllato da:
- Controllo degli accessi in base al ruolo di Kubernetes (tradizionalmente).
- Integrando il controllo degli accessi in base al ruolo di Azure con il servizio Azure Kubernetes per l'autorizzazione di Kubernetes.

Controllo degli accessi in base al ruolo di Azure per autorizzare l'accesso alla risorsa del servizio Azure Kubernetes

Con il controllo degli accessi in base al ruolo di Azure, puoi fornire agli utenti (o alle identità) l'accesso granulare alle risorse del servizio Azure Kubernetes in una o più sottoscrizioni. Ad esempio, potresti usare il ruolo Collaboratore al servizio Azure Kubernetes per ridimensionare e potenziare il cluster. Nel frattempo, un altro utente con il ruolo di amministratore del cluster del servizio Azure Kubernetes ha solo l'autorizzazione per eseguire il pull dell'amministratore kubeconfig.

Usare il controllo degli accessi in base al ruolo di Azure per definire l'accesso al file di configurazione Kubernetes nel servizio Azure Kubernetes.

Controllo degli accessi in base al ruolo di Azure per l'autorizzazione di Kubernetes

Con l'integrazione del controllo degli accessi in base al ruolo di Azure, il servizio Azure Kubernetes userà un server WebHook di autorizzazione Kubernetes per permetterti di gestire le autorizzazioni e le assegnazioni di risorse del cluster Kubernetes integrate di Microsoft Entra usando la definizione e le assegnazioni di ruolo di Azure.

Controllo degli accessi in base al ruolo di Azure per il flusso di autorizzazione di Kubernetes

Come illustrato nel diagramma precedente, quando si usa l'integrazione del controllo degli accessi in base al ruolo di Azure, tutte le richieste all'API Kubernetes seguiranno lo stesso flusso di autenticazione spiegato nella sezione integrazione di Microsoft Entra.

Se l'identità che effettua la richiesta esiste in Microsoft Entra ID, Azure agirà insieme al controllo degli accessi in base al ruolo di Kubernetes per autorizzare la richiesta. Se l'identità esiste all'esterno di Microsoft Entra ID (ad esempio, un account del servizio Kubernetes), l'autorizzazione rinvierà al normale controllo degli accessi in base al ruolo di Kubernetes.

In questo scenario puoi usare meccanismi e API di Controllo degli accessi in base al ruolo di Azure per assegnare agli utenti ruoli predefiniti o creare ruoli personalizzati, proprio come faresti con i ruoli Kubernetes.

Con questa funzionalità, non solo puoi assegnare agli utenti le autorizzazioni per la risorsa servizio Azure Kubernetes tra sottoscrizioni, ma puoi anche configurare il ruolo e le autorizzazioni all'interno di ognuno di questi cluster che controllano l'accesso all'API Kubernetes. Ad esempio, puoi concedere il ruolo Azure Kubernetes Service RBAC Reader nell'ambito della sottoscrizione. Il destinatario del ruolo sarà in grado di elencare e ottenere tutti gli oggetti Kubernetes da tutti i cluster senza modificarli.

Importante

Devi abilitare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes prima di usare questa funzionalità. Per ulteriori informazioni e indicazioni dettagliate, segui la guida pratica Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes.

Ruoli predefiniti

Il servizio Azure Kubernetes fornisce i seguenti ruoli predefiniti. Sono simili ai ruoli predefiniti di Kubernetes con alcune differenze, ad esempio il supporto dei CRL. Vedi l'elenco completo delle azioni consentite da ogni ruolo predefinito di Azure.

Ruolo	Descrizione
Ruolo con autorizzazioni di lettura per il Controllo degli accessi in base al ruolo del servizio Azure Kubernetes	Consente l'accesso in sola lettura per visualizzare la maggior parte degli oggetti in uno spazio dei nomi. Non consente la visualizzazione di ruoli o associazioni di ruolo. Non consente la visualizzazione di `Secrets`. La lettura del contenuto `Secrets` consente l'accesso alle `ServiceAccount` credenziali nello spazio dei nomi, che permette di accedere all'API come qualsiasi `ServiceAccount` nello spazio dei nomi (una forma di escalation dei privilegi).
Ruolo con autorizzazioni di scrittura per il Controllo degli accessi in base al ruolo del servizio Azure Kubernetes	Consente l'accesso in lettura/scrittura alla maggior parte degli oggetti in uno spazio dei nomi. Questo non consente la visualizzazione o la modifica di ruoli o associazioni di ruoli. Consente di accedere a `Secrets` ed eseguire pod come qualsiasi ServiceAccount nello spazio dei nomi, in modo che possa essere usato per ottenere i livelli di accesso API di qualsiasi ServiceAccount nello spazio dei nomi.
Amministratore del Controllo degli accessi in base al ruolo del servizio Azure Kubernetes	Consente l'accesso amministratore, destinato a essere concesso all'interno di uno spazio dei nomi. Consente l'accesso in lettura/scrittura alla maggior parte delle risorse in uno spazio dei nomi (o ambito del cluster), inclusa la possibilità di creare ruoli e associazioni di ruolo all'interno dello spazio dei nomi. Non consente l'accesso in scrittura alla quota di risorse o allo spazio dei nomi stesso.
Amministratore dei cluster del Controllo degli accessi in base al ruolo del servizio Azure Kubernetes	Consente all'utente con privilegi avanzati di eseguire qualsiasi azione su qualsiasi risorsa. Offre il controllo completo su ogni risorsa nel cluster e in tutti gli spazi dei nomi.

Integrazione di Microsoft Entra

Migliora la sicurezza del tuo cluster del servizio Azure Kubernetes con l'integrazione di Microsoft Entra. Microsoft Entra ID, nato da decenni di esperienza nella gestione delle identità aziendali, è un servizio di gestione delle directory e delle identità basato sul cloud multi-tenant, che combina i principali servizi directory, la gestione dell'accesso alle applicazioni e la protezione delle identità. Con Microsoft, è possibile integrare le identità locali nei cluster del servizio Azure Kubernetes per offrire una singola origine per la gestione e la sicurezza degli account.

Integrazione di Microsoft Entra con i cluster del servizio Azure Kubernetes

Con i cluster del servizio Azure Kubernetes integrati in Microsoft Entra, è possibile concedere a utenti o gruppi l'accesso alle risorse di Kubernetes all'interno di uno spazio dei nomi o tra i cluster.

Per ottenere un contesto di configurazione kubectl, un utente può eseguire il comando az servizio Azure Kubernetes get-credentials.
Quando un utente interagisce con il cluster del servizio Azure Kubernetes con kubectl, viene richiesto di accedere con le credenziali di Microsoft Entra.

Questo approccio offre un'unica origine per la gestione degli account utente e le credenziali della password. L'utente può accedere solo alle risorse come definito dall'amministratore del cluster.

L'autenticazione di Microsoft Entra viene fornita ai cluster del servizio Azure Kubernetes con OpenID Connect. OpenID Connect è un livello di gestione delle identità basato sul protocollo OAuth 2.0. Per altre informazioni su OpenID Connect, vedere la documentazione di OpenID Connect. Dall'interno del cluster Kubernetes viene usata l'Autenticazione del token del WebHook per verificare i token di autenticazione. L'autenticazione del token del webhook viene configurata e gestita come parte del cluster servizio Azure Kubernetes.

WebHook e server API

Flusso di autenticazione del webhook e del server API

Come illustrato nell'immagine precedente, il server API chiama il server WebHook del servizio Azure Kubernetes ed esegue i passaggi seguenti:

kubectl usa l'applicazione client Microsoft Entra per consentire agli utenti di accedere con il flusso di concessione dell'autorizzazione del dispositivo OAuth 2.0.
Microsoft Entra ID fornisce un access_token, un id_token e un refresh_token.
L'utente effettua una richiesta a kubectl con un access_token da kubeconfig.
kubectl invia l’access_token al server API.
Il server API è configurato con il server WebHook di autenticazione per eseguire la convalida.
Il server WebHook di autenticazione conferma che la firma del token Web JSON è valida controllando la chiave di firma pubblica di Microsoft Entra.
L'applicazione server usa le credenziali fornite dall'utente per eseguire query sulle appartenenze ai gruppi dell'utente connesso dall'API Microsoft Graph.
Una risposta viene inviata al server API con informazioni sull'utente, ad esempio l'attestazione UPN (User Principal Name) del token di accesso e l'appartenenza al gruppo dell'utente in base all'ID oggetto.
L'API esegue una decisione di autorizzazione basata sul ruolo Kubernetes/RoleBinding.
Una volta autorizzato, il server API restituisce una risposta a kubectl.
kubectl fornisce feedback all'utente.

Impara come integrare il servizio Azure Kubernetes con Microsoft Entra ID con le nostre procedure di integrazione di Microsoft Entra gestito dal servizio Azure Kubernetes .

Autorizzazioni del servizio Azure Kubernetes

Quando si crea un cluster, il servizio Azure Kubernetes genera o modifica le risorse necessarie (ad esempio le macchine virtuali e le schede di interfaccia di rete) per creare ed eseguire il cluster per conto dell'utente. Questa identità è distinta dall'autorizzazione di identità del cluster, che viene creata durante la creazione del cluster.

Identità che crea e opera le autorizzazioni del cluster

Le autorizzazioni seguenti sono necessarie per l'identità che crea e opera sul cluster.

Autorizzazione	Motivo
`Microsoft.Compute/diskEncryptionSets/read`	Necessarie per leggere l'ID del set di crittografia del disco.
`Microsoft.Compute/proximityPlacementGroups/write`	Necessarie per aggiornare i gruppi di posizionamento di prossimità.
`Microsoft.Network/applicationGateways/read` `Microsoft.Network/applicationGateways/write` `Microsoft.Network/virtualNetworks/subnets/join/action`	Necessarie per configurare i gateway applicazione e unirsi alla subnet.
`Microsoft.Network/virtualNetworks/subnets/join/action`	Necessarie per configurare il gruppo di sicurezza di rete per la subnet quando si usa una rete virtuale personalizzata.
`Microsoft.Network/publicIPAddresses/join/action` `Microsoft.Network/publicIPPrefixes/join/action`	Necessarie per configurare gli indirizzi IP pubblici in uscita in Load Balancer Standard.
`Microsoft.OperationalInsights/workspaces/sharedkeys/read` `Microsoft.OperationalInsights/workspaces/read` `Microsoft.OperationsManagement/solutions/write` `Microsoft.OperationsManagement/solutions/read` `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`	Necessarie per creare e aggiornare le aree di lavoro Log Analytics e il monitoraggio di Azure per i contenitori.
`Microsoft.Network/virtualNetworks/joinLoadBalancer/action`	Necessarie per configurare i pool back-end del servizio di bilanciamento del carico basati su IP.

Autorizzazioni di identità del cluster del servizio Azure Kubernetes

Le seguenti autorizzazioni vengono usate dall'identità del cluster del servizio Azure Kubernetes, creata e associata al cluster del servizio Azure Kubernetes. Ogni autorizzazione viene usata per i motivi seguenti:

Autorizzazione	Motivo
`Microsoft.ContainerService/managedClusters/*`	Necessaria per la creazione di utenti e il funzionamento del cluster
`Microsoft.Network/loadBalancers/delete` `Microsoft.Network/loadBalancers/read` `Microsoft.Network/loadBalancers/write`	Necessaria per configurare il servizio di bilanciamento del carico per un servizio LoadBalancer.
`Microsoft.Network/publicIPAddresses/delete` `Microsoft.Network/publicIPAddresses/read` `Microsoft.Network/publicIPAddresses/write`	Necessaria per trovare e configurare indirizzi IP pubblici per un servizio LoadBalancer.
`Microsoft.Network/publicIPAddresses/join/action`	Necessaria per la configurazione di indirizzi IP pubblici per un servizio LoadBalancer.
`Microsoft.Network/networkSecurityGroups/read` `Microsoft.Network/networkSecurityGroups/write`	Necessaria per creare o eliminare regole di sicurezza per un servizio LoadBalancer.
`Microsoft.Compute/disks/delete` `Microsoft.Compute/disks/read` `Microsoft.Compute/disks/write` `Microsoft.Compute/locations/DiskOperations/read`	Necessaria per configurare AzureDisks.
`Microsoft.Storage/storageAccounts/delete` `Microsoft.Storage/storageAccounts/listKeys/action` `Microsoft.Storage/storageAccounts/read` `Microsoft.Storage/storageAccounts/write` `Microsoft.Storage/operations/read`	Necessaria per configurare gli account di archiviazione per AzureFile o AzureDisk.
`Microsoft.Network/routeTables/read` `Microsoft.Network/routeTables/routes/delete` `Microsoft.Network/routeTables/routes/read` `Microsoft.Network/routeTables/routes/write` `Microsoft.Network/routeTables/write`	Necessaria per configurare le tabelle di routing e le route per i nodi.
`Microsoft.Compute/virtualMachines/read`	Necessaria per trovare informazioni per le macchine virtuali in una VMAS, ad esempio zone, dominio di errore, dimensioni e dischi dati.
`Microsoft.Compute/virtualMachines/write`	Necessaria per collegare AzureDisks a una macchina virtuale in una VMAS.
`Microsoft.Compute/virtualMachineScaleSets/read` `Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read` `Microsoft.Compute/virtualMachineScaleSets/virtualmachines/instanceView/read`	Necessaria per trovare informazioni per le macchine virtuali in un set di scalabilità di macchine virtuali, ad esempio zone, dominio di errore, dimensioni e dischi dati.
`Microsoft.Network/networkInterfaces/write`	Necessaria per aggiungere una macchina virtuale in una VMAS a un pool di indirizzi back-end del servizio di bilanciamento del carico.
`Microsoft.Compute/virtualMachineScaleSets/write`	Necessaria per aggiungere un set di scalabilità di macchine virtuali a pool di indirizzi back-end del servizio di bilanciamento del carico e ridimensionare i nodi in un set di scalabilità di macchine virtuali.
`Microsoft.Compute/virtualMachineScaleSets/delete`	Necessaria per eliminare un set di scalabilità di macchine virtuali in pool di indirizzi back-end del servizio di bilanciamento del carico e ridurre i nodi in un set di scalabilità di macchine virtuali.
`Microsoft.Compute/virtualMachineScaleSets/virtualmachines/write`	Necessaria per collegare AzureDisks e aggiungere una macchina virtuale da un set di scalabilità di macchine virtuali al servizio di bilanciamento del carico.
`Microsoft.Network/networkInterfaces/read`	Necessaria per cercare indirizzi IP interni e pool di indirizzi back-end del servizio di bilanciamento del carico per le macchine virtuali in una VMAS.
`Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/read`	Necessaria per cercare indirizzi IP interni e pool di indirizzi back-end del servizio di bilanciamento del carico per una macchina virtuale in un set di scalabilità di macchine virtuali.
`Microsoft.Compute/virtualMachineScaleSets/virtualMachines/networkInterfaces/ipconfigurations/publicipaddresses/read`	Necessaria per trovare indirizzi IP pubblici per una macchina virtuale in un set di scalabilità di macchine virtuali.
`Microsoft.Network/virtualNetworks/read` `Microsoft.Network/virtualNetworks/subnets/read`	Necessaria per verificare se esiste una subnet per il servizio di bilanciamento del carico interno in un altro gruppo di risorse.
`Microsoft.Compute/snapshots/delete` `Microsoft.Compute/snapshots/read` `Microsoft.Compute/snapshots/write`	Necessaria per configurare gli snapshot per AzureDisk.
`Microsoft.Compute/locations/vmSizes/read` `Microsoft.Compute/locations/operations/read`	Necessaria per trovare le dimensioni delle macchine virtuali per individuare i limiti del volume di AzureDisk.

Autorizzazioni aggiuntive per l'identità del cluster

Quando crei un cluster con attributi specifici hai bisogno delle seguenti autorizzazioni aggiuntive per l'identità del cluster. Poiché queste autorizzazioni non vengono assegnate automaticamente, devi aggiungerle all'identità del cluster dopo la creazione.

Autorizzazione	Motivo
`Microsoft.Network/networkSecurityGroups/write` `Microsoft.Network/networkSecurityGroups/read`	Necessario se usi un gruppo di sicurezza di rete in un altro gruppo di risorse. Necessario per configurare le regole di sicurezza per un servizio LoadBalancer.
`Microsoft.Network/virtualNetworks/subnets/read` `Microsoft.Network/virtualNetworks/subnets/join/action`	Necessario se usi una subnet in un altro gruppo di risorse, ad esempio una rete virtuale personalizzata.
`Microsoft.Network/routeTables/routes/read` `Microsoft.Network/routeTables/routes/write`	Necessario se si usa una subnet associata a una tabella di routing in un altro gruppo di risorse, ad esempio una rete virtuale personalizzata con una tabella di routing personalizzata. Necessario per verificare se esiste già una subnet per la subnet nell'altro gruppo di risorse.
`Microsoft.Network/virtualNetworks/subnets/read`	Necessario se si usa un servizio di bilanciamento del carico interno in un altro gruppo di risorse. Necessario per verificare se esiste già una subnet per il servizio di bilanciamento del carico interno nel gruppo di risorse.
`Microsoft.Network/privatednszones/*`	Necessario se usi una zona DNS privata in un altro gruppo di risorse, ad esempio un privateDNSZone personalizzato.

Accesso al nodo del servizio Azure Kubernetes

Per impostazione predefinita, l'accesso al nodo non è necessario per il servizio Azure Kubernetes. L'accesso seguente è necessario per il nodo se viene utilizzato un componente specifico.

Accesso	Motivo
`kubelet`	Necessario per concedere alla MSI l'accesso al Registro Azure Container.
`http app routing`	Necessario per l'autorizzazione di scrittura per "nome casuale".aksapp.io.
`container insights`	Necessario per concedere l'autorizzazione all'area di lavoro Log Analytics.

Riepilogo

Visualizza la tabella per un riepilogo rapido del modo in cui gli utenti possono eseguire l'autenticazione a Kubernetes quando è abilitata l'integrazione di Microsoft Entra. In tutti i casi, la sequenza di comandi dell'utente è:

Esegui az login per eseguire l'autenticazione in Azure.
Esegui az aks get-credentials per scaricare le credenziali per il cluster in .kube/config.
Esegui kubectl comandi.
- Il primo comando può attivare l'autenticazione basata su browser per l'autenticazione nel cluster, come descritto nella tabella seguente.

Nel portale di Azure puoi trovare:

La concessione di ruolo (concessione di ruolo di Azure RBAC) a cui si fa riferimento nella seconda colonna viene visualizzata nella scheda Controllo di accesso.
Il gruppo Cluster Admin Microsoft Entra viene visualizzato nella scheda Configurazione.
- Si trova anche con il nome di parametro --aad-admin-group-object-ids nell'interfaccia della riga di comando di Azure.

Descrizione	Concessione di ruolo richiesta	Amministratore del cluster Microsoft Entra group(s)	Quando utilizzare
Accesso amministratore legacy con certificato client	servizio Azure Kubernetes ruolo di amministratore del cluster. Questo ruolo permette di usare `az aks get-credentials` con il flag `--admin`, che scarica un certificato di amministratore del cluster legacy (non Microsoft Entra) nel `.kube/config` dell'utente. Questo è l'unico scopo di "ruolo amministratore cluster servizio Azure Kubernetes".	n/d	Se sei bloccato in modo permanente e non puoi accedere a un gruppo Microsoft Entra valido con accesso al cluster.
Microsoft Entra ID con (Cluster)RoleBindings manuale	Ruolo di utente del cluster del servizio Azure Kubernetes. Il ruolo "Utente" consente di usare `az aks get-credentials` senza il flag `--admin`. (Questo è l'unico scopo di "Ruolo di utente del cluster del servizio Azure Kubernetes".) Il risultato, in un cluster abilitato per Microsoft Entra ID, è il download di una voce vuota in `.kube/config`, che attiva l'autenticazione basata su browser quando viene usata per la prima volta da `kubectl`.	L'utente non si trova in nessuno di questi gruppi. Poiché l'utente non si trova in alcun gruppo di amministratori del cluster, i relativi diritti verranno controllati interamente da qualsiasi RoleBindings o ClusterRoleBindings configurato dagli amministratori del cluster. I (Cluster)RoleBindings nominano gli utenti di Microsoft Entra o i gruppi di Microsoft Entra come loro `subjects`. Se non sono state configurate associazioni di questo tipo, l'utente non sarà in grado di estrarre alcun comando `kubectl`.	Se vuoi un controllo degli accessi granulare e non stai usando il controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes. Nota che l'utente che configura le associazioni deve accedere con uno degli altri metodi elencati in questa tabella.
Microsoft Entra ID per membro del gruppo di amministrazione	Vedere sopra.	L'utente è membro di uno dei gruppi qui elencati. Il servizio Azure Kubernetes genera automaticamente un ClusterRoleBinding che associa tutti i gruppi elencati al ruolo Kubernetes `cluster-admin`. Gli utenti di questi gruppi possono quindi eseguire tutti i comandi `kubectl` come `cluster-admin`.	Se vuoi concedere agli utenti diritti di amministratore completi e non stai usando il controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes.
Microsoft Entra ID con controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes	Due ruoli: Il primo, Ruolo di utente del cluster del servizio Azure Kubernetes (come sopra). In secondo luogo, uno dei ruoli “RBAC (Controllo degli accessi in base al ruolo) del servizio Azure Kubernetes..." elencati in precedenza o un'alternativa personalizzata.	Il campo ruoli amministratore nella scheda Configurazione è irrilevante quando è abilitato il controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes.	Stai usando il controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes. Questo approccio ti offre un controllo con granularità fine, senza la necessità di configurare RoleBindings o ClusterRoleBindings.

Passaggi successivi

Per iniziare a usare il controllo degli accessi in base al ruolo di Microsoft Entra ID e Kubernetes, vedi Integrare Microsoft Entra ID con il servizio Azure Kubernetes.
Per le procedure consigliate associate, vedi Procedure consigliate per l'autenticazione e l'autorizzazione nel servizio Azure Kubernetes.
Per iniziare a usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes, vedi Usare il controllo degli accessi in base al ruolo di Azure per autorizzare l'accesso all'interno del cluster del servizio Azure Kubernetes (AKS).
Per iniziare a proteggere il tuo file kubeconfig, vedi Limitare l'accesso al file di configurazione del cluster.
Per iniziare a usare le identità gestite nel servizio Azure Kubernetes, vedi Usare un'identità gestita nel servizio Azure Kubernetes.

Per altre informazioni sui concetti fondamentali di Kubernetes e del servizio Azure Kubernetes, vedere gli articoli seguenti:

Condividi tramite