Identità e accesso del carico di lavoro Kubernetes

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

• Gestione delle identità e degli accessi di Microsoft Entra per AWS
• Eseguire il mapping dei concetti di AWS IAM a concetti simili di Azure

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

Gestione delle identità e degli accessi di Amazon EKS

Amazon EKS offre opzioni native per gestire l'identità e l'accesso all'interno dei pod Kubernetes. Queste opzioni includono i ruoli IAM per gli account del servizio e i ruoli collegati al servizio Amazon EKS.

Ruoli IAM per gli account di servizio

È possibile associare i ruoli IAM agli account del servizio Kubernetes. Questa associazione fornisce le autorizzazioni AWS per i contenitori all'interno di qualsiasi pod che usa l'account del servizio. I ruoli IAM per gli account del servizio offrono i vantaggi seguenti:

• Privilegio minimo: È possibile assegnare autorizzazioni IAM specifiche a un account del servizio, assicurando che solo i pod che usano tale account di servizio abbiano accesso a tali autorizzazioni. Questa configurazione elimina la necessità di concedere autorizzazioni estese al ruolo IAM del nodo per tutti i pod in un nodo. Questo approccio offre sicurezza avanzata e controllo granulare ed elimina la necessità di soluzioni partner, ad esempio kube2iam. Per altre informazioni, vedere ruoli IAM per gli account di servizio.

• Isolamento delle credenziali: Ogni contenitore all'interno di un pod può recuperare solo le credenziali per il ruolo IAM associato al rispettivo account del servizio. Questo isolamento garantisce che un contenitore non possa accedere alle credenziali appartenenti a un altro contenitore in un pod diverso.

• Verificabilità: Amazon EKS usa AWS CloudTrail per fornire l'accesso e la registrazione degli eventi, semplificando il controllo e la conformità retrospettivi.

Per ulteriori informazioni, vedere ruoli IAM per gli account di servizio.

Ruoli collegati al servizio Amazon EKS

I ruoli collegati al servizio Amazon EKS sono ruoli IAM univoci che si collegano direttamente ad Amazon EKS. Questi ruoli predefiniti includono le autorizzazioni necessarie per chiamare i servizi AWS per conto del ruolo associato. Il ruolo principale collegato al servizio per Amazon EKS è il ruolo IAM del nodo Amazon EKS .

Il daemon di nodi Amazon EKS usa il ruolo IAM del nodo kubelet Amazon EKS per effettuare chiamate API ai servizi AWS per conto del nodo. Il profilo dell'istanza IAM e i criteri associati forniscono le autorizzazioni per queste chiamate API. Questa configurazione semplifica la gestione dei ruoli IAM per i nodi all'interno del cluster EKS.

Per altre informazioni, vedere Usare ruoli collegati al servizio per Amazon EKS.

Altre informazioni sulla gestione delle identità e degli accessi

Oltre ai ruoli IAM per gli account del servizio e i ruoli collegati al servizio Amazon EKS, altri aspetti essenziali della gestione dell'identità e dell'accesso in Amazon EKS includono:

• Autorizzazione RBAC di Amazon EKS: Amazon EKS supporta il controllo degli accessi basato sui ruoli (RBAC). Usare questa funzionalità per definire autorizzazioni granulari per le risorse Kubernetes all'interno del cluster.

• AWS IAM: IAM offre una soluzione completa di gestione delle identità per i servizi AWS, incluso EKS. Usare IAM per creare e gestire utenti, gruppi e ruoli per controllare l'accesso alle risorse di EKS.

• Gruppi di sicurezza Amazon EKS: usare Amazon EKS per applicare le regole del gruppo di sicurezza ai pod eseguiti all'interno del cluster. Usare questa funzionalità per controllare il traffico in ingresso e in uscita.

Per altre informazioni, vedere Che cos'è Amazon EKS?.

Identità gestite del cluster AKS

I cluster AKS richiedono un'identità Microsoft Entra per accedere alle risorse di Azure, come i bilanciatori del carico e i dischi gestiti. È consigliabile usare le identità gestite per le risorse di Azure per autorizzare l'accesso da un cluster del servizio Azure Kubernetes ad altri servizi di Azure.

Tipi di identità gestiti

Gli sviluppatori spesso lottano con la gestione di segreti, credenziali, certificati e chiavi che consentono di proteggere la comunicazione tra i servizi. Le identità gestite eliminano la necessità di gestire queste credenziali. È possibile usare le identità gestite per autenticare il cluster del servizio Azure Kubernetes senza gestire le credenziali o includerle nel codice. Assegnare un ruolo di controllo degli accessi basato su ruolo di Azure a un'identità per concedere all'identità le autorizzazioni per risorse specifiche in Azure.

Due tipi di identità gestite includono:

• Assegnato dal sistema. È possibile usare alcune risorse di Azure, ad esempio le macchine virtuali, per abilitare un'identità gestita direttamente nella risorsa. Quando si abilita un'identità gestita assegnata dal sistema:

  • Viene creato un tipo speciale di entità servizio in Microsoft Entra ID per l'identità. Il principale del servizio è legato al ciclo di vita di quella risorsa di Azure. Quando la risorsa di Azure viene eliminata, Azure elimina automaticamente l'entità servizio.

  • Solo la risorsa di Azure può usare l'identità per richiedere token da Microsoft Entra ID.

  • L'utente autorizza l'identità gestita ad avere accesso a uno o più servizi.

  • Il nome dell'entità servizio assegnata dal sistema corrisponde al nome della risorsa di Azure per cui viene creata.

• Assegnata dall'utente. È possibile creare un'identità gestita come risorsa di Azure autonoma. È possibile creare un'identità gestita assegnata dall'utente e assegnarla a una o più risorse di Azure. Quando si abilita un'identità gestita assegnata dall'utente:

  • Viene creato un tipo speciale di entità servizio in Microsoft Entra ID per l'identità. L'entità principale del servizio viene gestita separatamente dalle risorse che lo utilizzano.

  • Possono essere usate più risorse.

  • L'utente autorizza l'identità gestita ad avere accesso a uno o più servizi.

È possibile utilizzare entrambi i tipi di identità gestita per autorizzare l'accesso alle risorse di Azure dal cluster AKS.

Per altre informazioni, vedere Tipi di identità gestita.

Identità gestite in AKS

È possibile usare i seguenti tipi di identità gestite con un cluster AKS:

• Un'identità gestita assegnata dal sistema è associata a una singola risorsa di Azure, ad esempio un cluster del servizio Azure Kubernetes. Esiste solo per il ciclo di vita del cluster.

• Un'identità gestita assegnata dall'utente è una risorsa autonoma di Azure che è possibile utilizzare per autorizzare l'accesso ad altri servizi Azure dal cluster AKS. Viene mantenuto separatamente dal cluster e possono essere usate più risorse di Azure.

• Un'identità gestita kubelet precreata è un'identità assegnata dall'utente facoltativa che kubelet può usare per accedere ad altre risorse in Azure. Se non viene specificata alcuna identità gestita assegnata dall'utente per il kubelet, AKS crea un'identità kubelet assegnata dall'utente nel gruppo di risorse del nodo.

Configurare le identità gestite per i cluster AKS

Quando si distribuisce un cluster AKS, viene creata automaticamente un'identità gestita assegnata dal sistema. È anche possibile creare il cluster con un'identità gestita assegnata dall'utente. Il cluster usa l'identità gestita per richiedere token da Microsoft Entra ID. I token autorizzano l'accesso ad altre risorse eseguite in Azure.

Quando si assegna un ruolo RBAC di Azure all'identità gestita, è possibile concedere al cluster le autorizzazioni per accedere a risorse specifiche. Ad esempio, è possibile assegnare all'identità gestita un ruolo di Azure RBAC che consente di accedere ai segreti in un insieme di credenziali di Azure. Usare questo approccio per autorizzare facilmente l'accesso al cluster senza gestire le credenziali.

Vantaggi e gestione delle identità gestite nel servizio Azure Kubernetes

Quando si usano le identità gestite nel servizio Azure Kubernetes, non è necessario effettuare il provisioning o ruotare i segreti. Azure gestisce le credenziali dell'identità. Pertanto, è possibile autorizzare l'accesso dalle applicazioni senza gestire segreti aggiuntivi.

Se si dispone già di un cluster del servizio Azure Kubernetes che usa un'identità gestita, è possibile aggiornare il cluster a un tipo diverso di identità gestita. Tuttavia, questo aggiornamento potrebbe introdurre un ritardo mentre i componenti del piano di controllo passano alla nuova identità. Questo processo può richiedere alcune ore. Durante questo periodo, i componenti del piano di controllo continuano a usare l'identità precedente fino alla scadenza del token.

Tipi di identità gestite in AKS

Il servizio Azure Kubernetes Service usa diversi tipi di identità gestite per abilitare vari servizi e componenti aggiuntivi integrati.

Per altre informazioni, vedere Usare un'identità gestita in AKS.

ID del carico di lavoro per Kubernetes

L'ID del carico di lavoro si integra con Kubernetes per consentire ai carichi di lavoro distribuiti dal cluster del servizio Azure Kubernetes di accedere alle risorse protette di Microsoft Entra, ad esempio Key Vault e Microsoft Graph. L'ID del carico di lavoro sfrutta le funzionalità native di Kubernetes per federarsi con i provider di identità esterni. Per ulteriori informazioni, vedere Usare l'ID del carico di lavoro con AKS.

Per usare l'ID del carico di lavoro, configurare un account del servizio in Kubernetes. I pod usano questo account del servizio per autenticare e accedere in modo sicuro alle risorse di Azure. L'ID del carico di lavoro funziona bene con le librerie client dei servizi di identità di Azure o la raccolta Microsoft Authentication Library. È necessario registrare l'applicazione in Microsoft Entra ID per gestire le autorizzazioni e il controllo di accesso per le identità.

Per utilizzare appieno l'identità del carico di lavoro in un cluster Kubernetes, configurare il cluster del Servizio Azure Kubernetes (AKS) per rilasciare token e pubblicare un documento di individuazione OpenID Connect (OIDC) per la convalida dei token. Per ulteriori informazioni, vedere Creare un provider OIDC su AKS.

È anche necessario configurare le applicazioni Microsoft Entra per considerare attendibili i token Kubernetes. Gli sviluppatori possono quindi configurare le distribuzioni per usare gli account del servizio Kubernetes per ottenere i token. L'ID del carico di lavoro scambia i token per i token di Microsoft Entra. I carichi di lavoro del cluster AKS possono utilizzare questi token Microsoft Entra per accedere in modo sicuro alle risorse protette in Azure.

Il diagramma seguente illustra come un 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 tramite gli SDK di Servizi di identità di Azure o Microsoft Authentication Library.

1. L'agente kubelet proietta un token di un account di servizio al processo in un percorso di file configurabile.

2. Il carico di lavoro Kubernetes invia a Microsoft Entra ID il token firmato e previsto dell'account di servizio 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 tramite il token di accesso Di Microsoft Entra.

Per altre informazioni sull'ID del carico di lavoro, vedere le risorse seguenti:

• Progetto open source ID di carico di lavoro
• Federazione delle identità del carico di lavoro
• Federazione dell'ID del carico di lavoro con Kubernetes
• Federazione dell'ID del carico di lavoro con provider di identità OIDC esterni
• Federazione minima dell'ID carico di lavoro
• Documentazione dell'ID del carico di lavoro
• Guida introduttiva all'ID del carico di lavoro
• Utilizzare l'ID del carico di lavoro per Kubernetes con un'identità gestita assegnata all'utente in un'applicazione .NET Standard

Carico di lavoro di esempio

Il carico di lavoro di esempio seguente viene eseguito in un cluster del servizio Azure Kubernetes ed è costituito da un front-end e da un servizio back-end. Questi servizi usano l'ID del carico di lavoro per accedere ai servizi di Azure, tra cui Key Vault, Azure Cosmos DB, account di archiviazione di Azure e namespace del servizio bus di Azure. Per configurare questo carico di lavoro di esempio, eseguire i prerequisiti seguenti:

1. Configurare un cluster AKS con OIDC issuer e identità del carico di lavoro abilitati.

2. Creare un account di servizio Kubernetes nello spazio dei nomi relativo al carico di lavoro.

3. Creare un'identità gestita assegnata dall'utente o un'applicazione registrata.

4. Stabilisci una credenziale di identità federata tra l'identità gestita di Microsoft Entra o l'applicazione registrata e l'account di servizio del carico di lavoro.

5. Assegnare i ruoli necessari con le autorizzazioni appropriate all'identità gestita di Microsoft Entra o all'applicazione registrata.

6. Distribuire il carico di lavoro e verificare l'autenticazione con l'identità del carico di lavoro.

Flusso dei messaggi dell'ID del carico di lavoro

In questo carico di lavoro di esempio, le applicazioni front-end e back-end acquisiscono token di sicurezza Microsoft Entra per accedere alle soluzioni PaaS (Platform as a Service) di Azure. Il diagramma seguente illustra il flusso dei messaggi.

Scaricare un file di Visio di questa architettura.

1. Kubernetes rilascia un token al pod quando il pod viene assegnato a un nodo. Questo token si basa sulle specifiche del pod o dell'implementazione.

2. Il pod invia il token OIDC rilasciato a Microsoft Entra ID per richiedere un token di Microsoft Entra per lo specifico appId e la risorsa.

3. Microsoft Entra ID verifica 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 l'ID del carico di lavoro fine a fine 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. Configurare le applicazioni Microsoft Entra per considerare attendibili i token Kubernetes.

3. Gli sviluppatori configurano le distribuzioni per usare gli account del servizio Kubernetes per ottenere i token Kubernetes.

4. L'ID del carico di lavoro scambia i token Kubernetes per i token Microsoft Entra.

5. I carichi di lavoro del cluster del servizio Azure Kubernetes usano i token Microsoft Entra per accedere alle risorse protette, ad esempio Microsoft Graph.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

• Paolo Salvatori | Ingegnere del servizio principale
• Martin Gjoševski | Senior Service Engineer

Altri collaboratori:

• Laura Nicolas | Senior Software Engineer
• Chad Kittel | Principal Software Engineer
• Prezzo ed | Senior Content Program Manager
• Theano Petersen | Redattore Tecnico

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

Passaggi successivi

• Usare un'entità servizio con il Servizio Azure Kubernetes (AKS)
• Usare un'identità gestita in AKS
• Percorso di apprendimento: Gestire l'identità e l'accesso in Microsoft Entra ID

" output is necessary.)

• AKS per i professionisti di Amazon EKS
• Monitoraggio e registrazione Kubernetes
• Accesso sicuro alla rete Kubernetes
• Opzioni di archiviazione per un cluster Kubernetes
• Gestione dei costi per Kubernetes
• Gestione del nodo e del pool di nodi Kubernetes
• Governance del cluster
• Gestione delle identità e degli accessi di Microsoft Entra per AWS