Modifica

Condividi tramite

Identità e accesso del carico di lavoro Kubernetes

Microsoft Entra ID
Servizio Azure Kubernetes

Questo articolo descrive in che modo Amazon Elastic Kubernetes Service (Amazon EKS) e servizio Azure Kubernetes (AKS) forniscono l'identità per i carichi di lavoro Kubernetes per accedere ai servizi della piattaforma cloud. Per un confronto dettagliato di Amazon Web Services (AWS) Identity and Access Management (IAM) e Microsoft Entra ID, vedere:

Questa guida illustra in che modo i cluster del servizio Azure Kubernetes, i servizi predefiniti e i componenti aggiuntivi usano identità gestite per accedere alle risorse di Azure, ad esempio i servizi di bilanciamento del carico e i dischi gestiti. L'articolo illustra anche come usare ID dei carichi di lavoro di Microsoft Entra in modo che i carichi di lavoro del servizio Azure Kubernetes possano accedere alle risorse di Azure senza che sia necessaria una stringa di connessione, una chiave di accesso o credenziali utente.

Nota

Questo articolo fa parte di una serie di articoli che aiutano i professionisti che hanno familiarità con Amazon EKS per comprendere servizio Azure Kubernetes (servizio Azure Kubernetes).

Gestione delle identità e degli accessi di Amazon EKS

Amazon EKS offre due opzioni native per chiamare i servizi AWS dall'interno di un pod Kubernetes: ruoli IAM per gli account del servizio e ruoli collegati al servizio Amazon EKS.

I ruoli IAM per gli account del servizio associano i ruoli IAM a un account del servizio Kubernetes. Questo account del servizio fornisce le autorizzazioni AWS per i contenitori in qualsiasi pod che usa l'account del servizio. I ruoli IAM per gli account del servizio offrono i vantaggi seguenti:

  • Privilegio minimo: non è necessario fornire autorizzazioni estese al ruolo IAM del nodo per i pod in tale nodo per chiamare le API AWS. È possibile definire l'ambito delle autorizzazioni IAM per un account del servizio e solo i pod che usano tale account del servizio hanno accesso a tali autorizzazioni. Questa funzionalità elimina anche la necessità di soluzioni di terze parti, ad kiam esempio o kube2iam.

  • Isolamento delle credenziali: un contenitore può recuperare solo le credenziali per il ruolo IAM associato all'account del servizio a cui appartiene. Un contenitore non ha mai accesso alle credenziali per un altro contenitore appartenente a un altro pod.

  • Verificabilità: Amazon CloudTrail fornisce accesso e registrazione eventi per garantire il controllo retrospettivo.

I ruoli collegati al servizio Amazon EKS sono ruoli IAM univoci collegati direttamente ad Amazon EKS. I ruoli collegati al servizio sono predefiniti da Amazon EKS e includono tutte le autorizzazioni necessarie per chiamare altri servizi AWS per conto del ruolo. Per il ruolo IAM del nodo Amazon EKS, il daemon di nodi kubelet Amazon EKS chiama le API AWS per conto del nodo. I nodi ottengono le autorizzazioni per queste chiamate API da un profilo di istanza IAM e i criteri associati.

Identità gestite del cluster del servizio Azure Kubernetes

Un cluster del servizio Azure Kubernetes richiede un'identità per accedere alle risorse di Azure, ad esempio i servizi di bilanciamento del carico e i dischi gestiti. Questa identità può essere un'identità gestita o un'entità servizio. Per impostazione predefinita, la creazione di un cluster del servizio Azure Kubernetes crea automaticamente un'identità gestita assegnata dal sistema. La piattaforma Azure gestisce l'identità e non è necessario effettuare il provisioning o ruotare i segreti. Per altre informazioni sulle identità gestite di Microsoft Entra, vedere Identità gestite per le risorse di Azure.

Il servizio Azure Kubernetes non crea automaticamente un'entità servizio, quindi se si vuole usare un'entità servizio, è necessario crearla. L'entità servizio scade alla fine ed è necessario rinnovarla per mantenere il funzionamento del cluster. La gestione delle entità servizio aggiunge complessità, quindi è più facile usare le identità gestite.

Le identità gestite sono essenzialmente wrapper per le entità servizio che semplificano la gestione. Gli stessi requisiti di autorizzazione si applicano sia alle entità servizio che alle identità gestite. Le identità gestite usano l'autenticazione basata su certificati. Ogni credenziale delle identità gestite ha una scadenza di 90 giorni e viene ruotata dopo 45 giorni.

Il servizio Azure Kubernetes usa tipi di identità gestiti assegnati dal sistema e assegnati dall'utente e queste identità non sono modificabili. Quando si crea o si usa una rete virtuale del servizio Azure Kubernetes, un disco di Azure collegato, un indirizzo IP statico, una tabella di route o un'identità assegnata dall'utente kubelet con risorse esterne al gruppo di risorse del nodo, l'interfaccia della riga di comando di Azure aggiunge automaticamente l'assegnazione di ruolo.

Se si usa un altro metodo per creare il cluster del servizio Azure Kubernetes, ad esempio un modello Bicep, un modello di Azure Resource Manager o un modulo Terraform, è necessario usare l'ID entità dell'identità gestita del cluster per eseguire un'assegnazione di ruolo. L'identità del cluster del servizio Azure Kubernetes deve avere almeno il ruolo Collaboratore rete nella subnet all'interno della rete virtuale. Per definire un ruolo personalizzato anziché usare il ruolo Collaboratore rete predefinito, sono necessarie le autorizzazioni seguenti:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Quando l'identità del cluster deve accedere a una risorsa esistente, ad esempio quando si distribuisce un cluster del servizio Azure Kubernetes in una rete virtuale esistente, è necessario usare un'identità gestita assegnata dall'utente. Se si usa un'identità del piano di controllo assegnata dal sistema, il provider di risorse non può ottenere il relativo ID entità prima di creare il cluster, quindi è impossibile creare le assegnazioni di ruolo appropriate prima del provisioning del cluster.

Riepilogo delle identità gestite

Il servizio Azure Kubernetes usa le identità gestite assegnate dall'utente seguenti per i servizi e i componenti aggiuntivi predefiniti.

Identità Nome Caso d'uso Autorizzazioni predefinite Usare la propria identità
Piano di controllo Nome del cluster del servizio Azure Kubernetes Gestisce le risorse del cluster, inclusi i servizi di bilanciamento del carico in ingresso e gli indirizzi IP pubblici gestiti dal servizio Azure Kubernetes, il ridimensionamento automatico del cluster e i driver CSI dei file di Azure e dischi di Azure Ruolo collaboratore per il gruppo di risorse del nodo Supportata
Kubelet Nome del cluster AKS-agentpool Esegue l'autenticazione con Registro Azure Container NA (per Kubernetes v1.15+) Supportata
Componente aggiuntivo HTTPApplicationRouting Gestisce le risorse di rete necessarie Ruolo lettore per il gruppo di risorse del nodo, ruolo Collaboratore per la zona DNS No
Componente aggiuntivo Gateway applicazione in ingresso Gestisce le risorse di rete necessarie Ruolo collaboratore per il gruppo di risorse del nodo No
Componente aggiuntivo omsagent Inviare metriche del servizio Azure Kubernetes a Monitoraggio di Azure Ruolo del server di pubblicazione delle metriche di monitoraggio No
Componente aggiuntivo Virtual-Node (ACIConnector) Gestisce le risorse di rete necessarie per Istanze di Azure Container Ruolo collaboratore per il gruppo di risorse del nodo No

Per altre informazioni, vedere Usare un'identità gestita nel servizio Azure Kubernetes.

ID dei carichi di lavoro di Microsoft Entra per Kubernetes

I carichi di lavoro Kubernetes richiedono le credenziali dell'applicazione Microsoft Entra per accedere alle risorse protette di Microsoft Entra, ad esempio Azure Key Vault e Microsoft Graph. Una sfida comune per gli sviluppatori consiste nella gestione di segreti e credenziali per proteggere la comunicazione tra diversi componenti di una soluzione.

ID dei carichi di lavoro di Microsoft Entra per Kubernetes elimina la necessità di gestire le credenziali per accedere a servizi cloud come Azure Cosmos DB, Azure Key Vault o Archiviazione BLOB di Azure. Un'applicazione del carico di lavoro ospitata dal servizio Azure Kubernetes può usare ID dei carichi di lavoro di Microsoft Entra per accedere a un servizio gestito di Azure usando un token di sicurezza Di Microsoft Entra, anziché credenziali esplicite come una stringa di connessione, un nome utente e una password o una chiave primaria.

Come illustrato nel diagramma seguente, il cluster Kubernetes diventa un'autorità di certificazione del token di sicurezza che emette token per gli account del servizio Kubernetes. È possibile configurare questi token per essere attendibili nelle applicazioni Microsoft Entra. I token possono quindi essere scambiati per i token di accesso di Microsoft Entra usando gli SDK di identità di Azure o Microsoft Authentication Library (MSAL).

Diagramma che mostra un flusso di lavoro semplificato per un'identità gestita di pod in Azure.

  1. L'agente kubelet proietta un token dell'account del servizio al carico di lavoro in un percorso di file configurabile.
  2. Il carico di lavoro Kubernetes invia il token dell'account del servizio firmato proiettato a Microsoft Entra ID e richiede un token di accesso.
  3. Microsoft Entra ID usa un documento di individuazione OIDC per verificare l'attendibilità sull'identità gestita definita dall'utente o sull'applicazione registrata e convalidare il token in ingresso.
  4. Microsoft Entra ID rilascia un token di accesso alla sicurezza.
  5. Il carico di lavoro Kubernetes accede alle risorse di Azure usando il token di accesso Microsoft Entra.

ID dei carichi di lavoro di Microsoft Entra federazione per Kubernetes è attualmente supportata solo per le applicazioni Microsoft Entra, ma lo stesso modello potrebbe potenzialmente estendersi alle identità gestite di Azure.

Per altre informazioni, automazione e documentazione per ID dei carichi di lavoro di Microsoft Entra, vedere:

Carico di lavoro di esempio

Il carico di lavoro di esempio esegue un front-end e un servizio back-end in un cluster del servizio Azure Kubernetes. I servizi del carico di lavoro usano ID dei carichi di lavoro di Microsoft Entra per accedere ai servizi di Azure seguenti usando i token di sicurezza di Microsoft Entra:

  • Azure Key Vault
  • Azure Cosmos DB
  • account di archiviazione di Azure
  • Spazio dei nomi del bus di servizio di Azure

Prerequisiti

  1. Configurare un cluster del servizio Azure Kubernetes con l'autorità di certificazione OIDC abilitata.
  2. Installare il webhook di ammissione di modifica.
  3. Creare un account del servizio Kubernetes per i carichi di lavoro.
  4. Creare un'applicazione Microsoft Entra come illustrato nell'argomento di avvio rapido.
  5. Assegnare ruoli con le autorizzazioni appropriate alle applicazioni registrate di Microsoft Entra necessarie.
  6. Stabilire una credenziale di identità federata tra l'applicazione Microsoft Entra e l'emittente e l'oggetto dell'account del servizio.
  7. Distribuire l'applicazione del carico di lavoro nel cluster del servizio Azure Kubernetes.

flusso di messaggi ID dei carichi di lavoro di Microsoft Entra

Le applicazioni del servizio Azure Kubernetes ottengono token di sicurezza per l'account del servizio dall'autorità emittente OIDC del cluster del servizio Azure Kubernetes. ID dei carichi di lavoro di Microsoft Entra scambia i token di sicurezza con i token di sicurezza emessi da Microsoft Entra ID e le applicazioni usano i token di sicurezza rilasciati da Microsoft Entra ID per accedere alle risorse di Azure.

Il diagramma seguente illustra come le applicazioni front-end e back-end acquisiscono i token di sicurezza di Microsoft Entra per usare i servizi PaaS (Platform as a Service) di Azure.

Diagramma che mostra un'applicazione di esempio che usa ID dei carichi di lavoro di Microsoft Entra.

Scaricare un file di Visio di questa architettura.

  1. Kubernetes rilascia un token al pod quando è pianificato in un nodo, in base alla specifica di pod o distribuzione.
  2. Il pod invia il token EIDC rilasciato a Microsoft Entra ID per richiedere un token Microsoft Entra per la risorsa e specifica appId .
  3. Microsoft Entra ID controlla l'attendibilità nell'applicazione e convalida il token in ingresso.
  4. Microsoft Entra ID rilascia un token di sicurezza: {sub: appId, aud: requested-audience}.
  5. Il pod usa il token Microsoft Entra per accedere alla risorsa di Azure di destinazione.

Per usare ID dei carichi di lavoro di Microsoft Entra end-to-end in un cluster Kubernetes:

  1. Configurare il cluster del servizio Azure Kubernetes per rilasciare token e pubblicare un documento di individuazione OIDC per consentire la convalida di questi token.
  2. Le applicazioni Microsoft Entra vengono configurate in modo da considerare attendibili i token Kubernetes.
  3. Gli sviluppatori configurano le distribuzioni per usare gli account del servizio Kubernetes per ottenere i token Kubernetes.
  4. ID dei carichi di lavoro di Microsoft Entra scambia i token Kubernetes per i token Microsoft Entra.
  5. I carichi di lavoro del cluster del servizio Azure Kubernetes usano i token di Microsoft Entra per accedere a risorse protette, ad esempio Microsoft Graph.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi