Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive in che modo il servizio Azure Kubernetes decide cosa può fare un chiamante autenticato con l'API Kubernetes. Illustra i due modelli di autorizzazione supportati da Azure Kubernetes Service e il controllo dettagliato delle risorse personalizzate con le condizioni di Azure ABAC.
Per informazioni su come AKS autentica i chiamanti, vedere Concetti relativi all'autenticazione del cluster.
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.
Autorizzare l'API Kubernetes
Dopo l'autenticazione di un chiamante, il servizio Azure Kubernetes valuta se il chiamante è autorizzato a eseguire l'azione richiesta. AKS supporta due modelli di autorizzazione per l'API Kubernetes.
- Controllo degli accessi basato sui ruoli in Kubernetes. Modello di autorizzazione Kubernetes nativo. Le autorizzazioni vengono definite come oggetti
RoleeClusterRolee concesse a soggetti tramite oggettiRoleBindingeClusterRoleBindingarchiviati in ogni cluster. - Autorizzazione dell'ID Microsoft Entra. Webhook di autorizzazione AKS che delega le decisioni di autorizzazione a Microsoft Entra ID. Le autorizzazioni vengono concesse come assegnazioni di ruolo di Azure alle identità di Entra ID e possono essere facoltativamente perfezionate con le condizioni ABAC di Azure.
È possibile usare entrambi i modelli nello stesso cluster. Si consiglia di utilizzare l'autorizzazione Microsoft Entra ID come predefinita e di riservare il controllo degli accessi basato sui ruoli di Kubernetes per le autorizzazioni intraclustro con granularità fine. Nella parte restante di questa sezione viene illustrato perché e quando usarli.
Kubernetes RBAC (Controllo degli accessi in base al ruolo)
RBAC di Kubernetes è il modello di autorizzazione upstream di Kubernetes. È possibile creare Role o ClusterRole oggetti che concedono verbi (ad esempio get, list, create) alle risorse (ad esempio pods, deployments) e associarli a soggetti (utenti, gruppi o account di servizio) usando RoleBinding o ClusterRoleBinding oggetti . L'autorizzatore RBAC integrato del server API Kubernetes valuta questi collegamenti ad ogni richiesta.
Usare il controllo degli accessi in base al ruolo di Kubernetes quando si desidera:
- Controllo di accesso con granularità fine, intra-cluster, per spazio dei nomi creato come manifesti Kubernetes insieme ai carichi di lavoro protetti.
- Autorizzazione gestita da GitOps che si trova nella stessa fonte di verità della configurazione dell'applicazione.
- Autorizzazioni per gli account del servizio in cluster usati dai carichi di lavoro per chiamare l'API Kubernetes.
Le autorizzazioni RBAC di Kubernetes sono limitate a un singolo cluster. Per applicare lo stesso criterio a molti cluster, è necessario applicare i manifesti a ogni cluster (in genere tramite GitOps). Usa gli utenti e i gruppi di Microsoft Entra come soggetti negli oggetti RoleBinding e ClusterRoleBinding di Kubernetes, in modo tale che le identità personali continuino a provenire dal tuo archivio centrale.
Per informazioni generali sul modello RBAC di Kubernetes, consultare la documentazione principale di Kubernetes. Per la configurazione in AKS, vedere Usare Kubernetes RBAC con l'integrazione in Microsoft Entra.
Autorizzazione dell'ID Microsoft Entra per l'API Kubernetes
Con l'autorizzazione di Entra ID, AKS distribuisce un webhook di autorizzazione che delega le decisioni di autorizzazione dell'API Kubernetes a Entra ID. Quando una richiesta raggiunge il server API, il webhook chiama l'API Entra ID checkaccess per valutare le assegnazioni di ruolo di Azure del chiamante (e le eventuali condizioni ABAC associate) e restituisce una decisione di autorizzazione o negazione.
L'autorizzazione Entra ID offre i seguenti vantaggi rispetto alla gestione dei manifesti RBAC di Kubernetes in ciascun cluster.
- Piano di gestione delle identità singolo. Gli stessi utenti, gruppi e entità servizio di Microsoft Entra che regolano l'accesso alle risorse di Azure regolano anche l'accesso all'API Kubernetes. Non esiste una directory utente separata di cui effettuare il provisioning o la rotazione.
- Assegnare una sola volta, gestire molti cluster. Le assegnazioni di ruolo di Azure possono essere effettuate nell'ambito della sottoscrizione, del gruppo di gestione o del gruppo di risorse. Una singola assegnazione di ruolo all'interno di un gruppo di risorse concede l'accesso a ogni cluster AKS corrente e futuro nel gruppo di risorse. Con RBAC di Kubernetes, è necessario applicare i manifesti singolarmente a ogni cluster.
- Accesso condizionale e Privileged Identity Management (PIM). L'accesso al cluster eredita automaticamente i criteri di accesso condizionale Entra ID esistenti dell'organizzazione (ad esempio l'autenticazione a più fattori o le restrizioni basate sulla posizione) e può essere aumentato tramite PIM.
- Controllo centralizzato. Ogni modifica dell'assegnazione di ruolo viene registrata nel log attività di Azure insieme ad altre modifiche alle risorse di Azure, quindi è disponibile un audit trail per la governance dell'accesso al cluster.
- Vincoli di risorse personalizzate con granularità fine. Con condizioni ABAC, è possibile limitare l'accesso a specifici gruppi e tipologie di risorse personalizzate (CRD) senza dover scrivere manifesti RBAC per ogni cluster Kubernetes.
Il servizio AKS fornisce i seguenti ruoli predefiniti per l'autorizzazione Entra ID:
| Ruolo | Description |
|---|---|
| Lettore RBAC Azure Kubernetes Service | Accesso in sola lettura alla maggior parte degli oggetti in uno spazio dei nomi. Non consente la visualizzazione di ruoli, associazioni di ruoli o Secrets. |
| Scrittore RBAC del servizio Azure Kubernetes | Accesso in lettura/scrittura alla maggior parte degli oggetti in uno spazio dei nomi. Non consente la visualizzazione o la modifica di ruoli o associazioni di ruolo. |
| Amministratore RBAC di Azure Kubernetes Service | Accesso in lettura/scrittura alla maggior parte delle risorse in uno spazio dei nomi, oltre alla possibilità di creare ruoli e associazioni di ruolo all'interno dello spazio dei nomi. |
| Amministratore di cluster del servizio Azure Kubernetes RBAC | Controllo completo su tutte le risorse nel cluster, in tutti i namespace. |
Per i modelli di autorizzazione personalizzati, è possibile creare definizioni di ruolo personalizzate destinate a gruppi di API Kubernetes specifici usando le Microsoft.ContainerService azioni dei dati del provider di risorse. Per esempi di configurazione dettagliata e di ruoli personalizzati, vedere Usare l'autorizzazione microsoft Entra ID per l'API Kubernetes.
Comparison
| Capability | Kubernetes RBAC (Controllo degli accessi in base al ruolo) | Autorizzazione Entra ID |
|---|---|---|
| Fonte dell'identità | Utenti, gruppi, account del servizio Kubernetes | Identità ID Microsoft Entra |
| Ambito di una singola concessione | Un cluster | Risorsa, gruppo di risorse, sottoscrizione o gruppo di gestione |
| Governance multi-cluster | Applicare manifesti a ogni cluster (in genere GitOps) | Un'assegnazione di ruolo a un ambito superiore regola molti cluster |
| Accesso condizionale/PIM | Non supportato | Ereditato da Entra ID |
| Traccia di controllo | Log di controllo del cluster | Log attività di Azure |
| Filtrare l'accesso in base al gruppo o al tipo CRD | Creare oggetti PER CRD Role |
Usare gli attributi della condizione ABAC nell'assegnazione di ruolo |
Limitare l'accesso alle risorse personalizzate con condizioni del controllo degli accessi basato sugli attributi
Quando si concede l'accesso in lettura generale tramite l'autorizzazione di Microsoft Entra ID, ma si desidera limitare quali risorse personalizzate (CRDs) l'assegnatario può leggere, è necessario allegare una condizione di Azure ABAC all'assegnazione di ruolo.
Senza condizioni ABAC, per leggere le risorse personalizzate è necessario un carattere jolly come Microsoft.ContainerService/managedClusters/*/read, che copre ogni CRD in ogni cluster nell'ambito. Con l'ABAC (controllo degli accessi basato sugli attributi), è possibile associare una condizione che limita l'accesso a specifici gruppi e tipi CRD, ad esempio consentire templates.gatekeeper.sh mentre si blocca kyverno.io, senza dover scrivere manifesti RBAC per ogni cluster.
Per l'autorizzazione dell'API Kubernetes, è possibile filtrare l'accesso alle risorse personalizzate in base al gruppo di API e al tipo usando gli attributi seguenti:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Per informazioni generali su Azure ABAC (controllo degli accessi basato su attributi), vedere Che cosa sono le condizioni di assegnazione di ruolo di Azure?. Per la configurazione dettagliata, vedere Limitare l'accesso alle risorse personalizzate usando le condizioni del controllo degli accessi in base al ruolo.