Condividi tramite


Opzioni di accesso e identità per il servizio Azure Kubernetes abilitato da Azure Arc

Si applica a: Servizio Azure Kubernetes in Locale di Azure, versione 23H2

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

Il controllo degli accessi in base al ruolo di Kubernetes e il controllo degli accessi in base al ruolo di Azure consentono di proteggere l'accesso al cluster e fornire solo le autorizzazioni minime necessarie per 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, si definiscono le autorizzazioni utente come ruolo. Concedere le autorizzazioni all'interno di uno spazio dei nomi Kubernetes usando i ruoli.

I ruoli Kubernetes concedono le autorizzazioni e non negano le autorizzazioni. Per concedere le autorizzazioni per l'intero cluster o per le risorse del cluster all'esterno di uno spazio dei nomi specifico, è possibile usare 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, assegnare le autorizzazioni di controllo degli accessi in base al ruolo di Kubernetes con 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. Vedere Controllare l'accesso con Microsoft Entra ID e controllo degli accessi in base al ruolo di Kubernetes

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 ruoli nell'intero cluster o a risorse cluster esterne a uno spazio dei nomi specifico, usare 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.

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 dell'account del servizio vengono archiviate come segreti Kubernetes, consentendo loro di essere usate dai pod autorizzati per comunicare con il server 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 identità in Kubernetes, vedere Autenticazione di Kubernetes.

Controllo dell'accesso basato sui ruoli di Azure

Il Controllo di accesso basato sui ruoli di Azure è un sistema di autorizzazione basato su Azure Resource Manager che offre una gestione degli accessi con granularità fine delle 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 il funzionamento completo di un cluster Arc 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 il servizio Azure Kubernetes abilitato dalle API di Azure Arc.
    • Eseguire il pull dell'amministratore , kubeconfig basato su certificati.
    • Eseguire il pull dell'ID Entra abilitato kubeconfig.
  • Accesso all'API Kubernetes. Questo accesso è controllato da:
    • Controllo degli accessi in base al ruolo di Kubernetes o
    • 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. Sono disponibili tre ruoli per questa azione del piano di controllo: servizio Azure Kubernetes ruolo di amministratore del cluster Arc, ruolo utente del cluster servizio Azure Kubernetes Arc e ruolo collaboratore arc servizio Azure Kubernetes. Ogni ruolo ha un ambito di autorizzazione diverso, come descritto in Ruoli predefiniti di Azure per contenitori. Ad esempio, è possibile usare il ruolo collaboratore arc servizio Azure Kubernetes per creare, ridimensionare e aggiornare il cluster. Nel frattempo, un altro utente con il ruolo di amministratore del cluster servizio Azure Kubernetes Arc ha solo l'autorizzazione per eseguire il pull di kubeconfig amministratore.

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 usa un server webhook di autorizzazione Kubernetes per gestire le autorizzazioni e le assegnazioni di risorse del cluster Kubernetes integrate di Microsoft Entra usando la definizione di ruolo e le assegnazioni di ruolo di Azure.

Diagramma del flusso di autorizzazione.

Come illustrato in questo diagramma, quando si usa l'integrazione del controllo degli accessi in base al ruolo di Azure, tutte le richieste all'API Kubernetes seguono lo stesso flusso di autenticazione descritto in Integrazione di Microsoft Entra.

Se l'identità che effettua la richiesta esiste in Microsoft Entra ID, i team di Azure con il 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 rinvia 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. Per questa azione del piano dati sono disponibili quattro ruoli predefiniti, ognuno con il proprio ambito di autorizzazioni, come descritto nella sezione Ruoli predefiniti.

Importante

È necessario abilitare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione kubernetes prima di eseguire l'assegnazione di ruolo. Per altre informazioni e istruzioni dettagliate, vedere Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione kubernetes.

Ruoli predefiniti

Il servizio Azure Kubernetes abilitato da Arc fornisce i cinque ruoli predefiniti seguenti. 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
Utente del cluster Kubernetes abilitato per Azure Arc Consente di recuperare il file kubeconfig basato su Cluster Connect per gestire i cluster da qualsiasi posizione.
Visualizzatore di Kubernetes con abilitazione di Azure Arc Consente l'accesso in sola lettura per visualizzare la maggior parte degli oggetti in uno spazio dei nomi.
Non consente la visualizzazione dei segreti, perché l'autorizzazione di lettura per i segreti consente l'accesso alle credenziali ServiceAccount nello spazio dei nomi. Queste credenziali a loro volta consentono l'accesso all'API tramite tale valore ServiceAccount (una forma di escalation dei privilegi).
Ruolo con autorizzazioni di scrittura per Kubernetes con abilitazione di Azure Arc Consente l'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. Tuttavia, questo ruolo consente l'accesso ai segreti e l'esecuzione di pod come qualsiasi valore ServiceAccount nello spazio dei nomi, in modo che possa essere usato per ottenere i livelli di accesso api di qualsiasi valore ServiceAccount nello spazio dei nomi.
Amministratore di Kubernetes con abilitazione di Azure Arc Consente l'accesso amministratore. Deve essere concesso all'interno di uno spazio dei nomi tramite RoleBinding. Se viene usato in RoleBinding, consente l'accesso in lettura/scrittura alla maggior parte delle risorse in uno spazio dei nomi, inclusa la possibilità di creare ruoli e associazioni di ruolo all'interno dello spazio dei nomi. Questo ruolo non consente l'accesso in scrittura alla quota di risorse o allo spazio dei nomi stesso.
Amministratore del cluster di Kubernetes con abilitazione di Azure Arc Consente l'accesso "superuser" per eseguire qualsiasi azione su qualsiasi risorsa. Quando viene usato in ClusterRoleBinding, offre il controllo completo su ogni risorsa nel cluster e in tutti gli spazi dei nomi. Quando lo si usa in RoleBinding, fornisce il controllo completo su ogni risorsa nello spazio dei nomi dell'associazione di ruoli, incluso lo spazio dei nomi stesso.

Integrazione di Microsoft Entra

Migliora la sicurezza del tuo cluster del servizio Azure Kubernetes con l'integrazione di Microsoft Entra. Basata sull'esperienza di gestione delle identità aziendali, Microsoft Entra ID è un servizio di gestione delle identità e directory multi-tenant basato sul cloud che combina i servizi directory di base, la gestione degli accessi 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.

Diagramma di flusso che mostra l'integrazione di Entra.

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

  • Per ottenere un contesto di configurazione kubectl , eseguire il comando az aksarc get-credentials .
  • Quando un utente interagisce con il cluster del servizio Azure Kubernetes usando 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 definite dall'amministratore del cluster Kubernetes.

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 token webhook per verificare i token di autenticazione. L'autenticazione del token del webhook viene configurata e gestita come parte del cluster servizio Azure Kubernetes.

Riepilogo

La tabella seguente contiene un riepilogo 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 è:

  1. Esegui az login per eseguire l'autenticazione in Azure.
  2. Eseguire az aksarc get-credentials per scaricare le credenziali per il cluster Kubernetes in .kube/config.
  3. Esegui kubectl comandi.
    • Il primo comando può attivare l'autenticazione basata su browser per l'autenticazione nel cluster Kubernetes, come descritto nella tabella seguente.
Descrizione Concessione di ruolo richiesta Gruppi di Microsoft Entra amministratore del cluster Quando utilizzare
Account di accesso amministratore con certificato client servizio Azure Kubernetes ruolo di amministratore del cluster Arc. Questo ruolo consente di az aksarc get-credentials usare con il --admin flag , che scarica un certificato di amministratore del cluster non Microsoft Entra nel file con estensione kube/config dell'utente. Questo è l'unico scopo del ruolo di amministratore di Azure Kubernetes. n/d Se sei bloccato in modo permanente e non puoi accedere a un gruppo Microsoft Entra valido con accesso al cluster.
ID Microsoft Entra con RoleBindings manuale (cluster) servizio Azure Kubernetes ruolo utente cluster Arc. Il ruolo Utente consente di az aksarc get-credentials usare senza il --admin flag . Questo è l'unico scopo del ruolo utente cluster di 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. Poiché l'utente non si trova in alcun gruppo di amministrazione del cluster, i relativi diritti sono controllati interamente da qualsiasi RoleBindings o ClusterRoleBindings configurato dagli amministratori del cluster. I RoleBindings (Cluster) nominano gli utenti di Microsoft Entra o i gruppi di Microsoft Entra come soggetti. Se non sono state configurate associazioni di questo tipo, l'utente non può escute 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. Si noti che l'utente che configura le associazioni deve accedere usando uno degli altri metodi elencati in questa tabella.
Microsoft Entra ID by member of cluster admin Microsoft Entra group (impostato usando --aad-admin-group-object-ids il flag nell'interfaccia della riga di comando di Azure) Uguale a quello precedente. 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 si vuole concedere agli utenti diritti di amministratore completi e non si usa il controllo degli accessi in base al ruolo di Azure per l'autorizzazione kubernetes.
ID Microsoft Entra con il controllo degli accessi in base al ruolo di Azure per l'autorizzazione Kubernetes Due ruoli:
servizio Azure Kubernetes ruolo utente cluster Arc (come descritto in precedenza).
Uno dei ruoli di Azure Arc Kubernetes descritti in precedenza o una propria alternativa personalizzata.
Il campo Ruoli di amministratore nella scheda Configurazione è irrilevante quando l'autorizzazione di Controllo degli accessi in base al ruolo di Azure per Kubernetes è abilitata. Si usa 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