Procedure consigliate per l'autenticazione e l'autorizzazione nel servizio Azure Kubernetes (AKS)

Durante la distribuzione e la gestione dei cluster nel servizio Azure Kubernetes (AKS), è necessario implementare opportune modalità per gestire l'accesso a risorse e servizi. Senza questi controlli:

• Gli account potrebbero avere accesso a risorse e servizi non necessari.
• Il rilevamento delle credenziali usate per apportare modifiche può essere difficile.

In questo articolo vengono illustrate le procedure consigliate che un operatore del cluster può seguire per gestire l'accesso e l'identità per i cluster del servizio Azure Kubernetes. Nello specifico:

Usare Microsoft Entra ID

Materiale sussidiario sulle procedure consigliate

Distribuire i cluster del servizio Azure Kubernetes con l'integrazione di Microsoft Entra. L'uso di Microsoft Entra ID centralizza il livello di gestione delle identità. Qualsiasi modifica all'account utente o allo stato del gruppo viene aggiornata automaticamente nell'accesso al cluster servizio Azure Kubernetes. Definire l'ambito di utenti o gruppi per la quantità minima di autorizzazioni usando Roles, ClusterRoles o Bindings.

Gli sviluppatori e i proprietari delle applicazioni del cluster Kubernetes hanno bisogno di accedere a risorse diverse. Kubernetes non offre una soluzione di gestione delle identità per controllare le risorse con cui gli utenti possono interagire. È possibile invece integrare il cluster con una soluzione di gestione delle identità esistente, ad esempio Microsoft Entra ID, una soluzione di gestione delle identità pronta per l'organizzazione.

Con i cluster integrati di Microsoft Entra in servizio Azure Kubernetes, è possibile creare Roles o ClusterRoles che definiscono le autorizzazioni di accesso alle risorse. Quindi è possibile associare i ruoli a utenti o gruppi di Microsoft Entra ID. Altre informazioni sul controllo degli accessi in base al ruolo di Kubernetes sono disponibili nella sezione successiva. L'integrazione di Microsoft Entra e la modalità di controllo dell'accesso alle risorse possono essere visualizzate nel diagramma seguente:

1. Lo sviluppatore viene autenticato con Microsoft Entra ID.
2. L'endpoint di emissione del token di Microsoft Entra restituisce il token di accesso.
3. Lo sviluppatore esegue un'azione usando il token di Microsoft Entra, ad esempio kubectl create pod.
4. Kubernetes convalida il token con Microsoft Entra ID e recupera le appartenenze al gruppo dello sviluppatore.
5. Vengono applicati il controllo degli accessi in base al ruolo di Kubernetes e i criteri del cluster.
6. La richiesta dello sviluppatore ha esito positivo o negativo a seconda della precedente convalida dell'appartenenza al gruppo di Microsoft Entra e dei criteri e del controllo degli accessi in base al ruolo di Kubernetes.

Per creare un cluster del servizio Azure Kubernetes che usa Microsoft Entra ID, vedere Integrare Microsoft Entra ID con il servizio Azure Kubernetes.

Usare il controllo degli accessi in base al ruolo di Kubernetes (RBAC di Kubernetes)

Materiale sussidiario sulle procedure consigliate

Definire le autorizzazioni di utenti o gruppi per le risorse del cluster con il controllo degli accessi in base al ruolo di Kubernetes. Creare ruoli e associazioni che assegnano il numero minimo di autorizzazioni richieste. Consentire l'integrazione con Microsoft Entra ID in modo che qualsiasi modifica allo stato dell'utente o all'appartenenza al gruppo venga automaticamente aggiornata e l'accesso alle risorse del cluster sia corrente.

In Kubernetes è possibile fornire un controllo di accesso granulare alle risorse del cluster. È possibile definire le autorizzazioni a livello di cluster o per spazi dei nomi specifici. È possibile determinare quali risorse possono essere gestite e con quali autorizzazioni. È possibile quindi applicare questi ruoli a utenti o gruppi con un'associazione. Per altre informazioni su ruoli, ClusterRole e associazioni, vedere Opzioni di accesso e identità per il servizio Azure Kubernetes.

Ad esempio, è possibile creare un ruolo con accesso completo alle risorse dello spazio dei nomi denominato finance-app, come illustrato nell'esempio di manifesto YAML seguente:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

È possibile quindi creare un RoleBinding e associare l'utente di Microsoft Entra developer1@contoso.com, come illustrato nel manifesto YAML seguente:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Quando developer1@contoso.com viene autenticato nel cluster servizio Azure Kubernetes, si dispone di autorizzazioni complete per le risorse nello spazio dei nomi finance-app. In questo modo, l'accesso alle risorse viene separato e controllato logicamente. Usare il controllo degli accessi in base al ruolo di Kubernetes con l'integrazione di Microsoft Entra ID.

Per informazioni su come usare i gruppi di Microsoft Entra per controllare l'accesso alle risorse Kubernetes usando il controllo degli accessi in base al ruolo di Kubernetes, vedere Controllare l'accesso alle risorse del cluster usando il controllo degli accessi in base al ruolo e le identità di Microsoft Entra nel servizio Azure Kubernetes.

Usare il controllo degli accessi in base al ruolo di Azure

Materiale sussidiario sulle procedure consigliate

Usare il controllo degli accessi in base al ruolo di Azure per definire le autorizzazioni minime obbligatorie di utenti o gruppi relativamente alle risorse del servizio Azure Kubernetes in una o più sottoscrizioni.

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.

  Questo livello di accesso consente di:

  • Controllare il ridimensionamento o l'aggiornamento del cluster usando le API del servizio Azure Kubernetes
  • Eseguire il pull di kubeconfig.

  Per informazioni su come controllare l'accesso alla risorsa del servizio Azure Kubernetes e a kubeconfig, vedere Limitare l'accesso al file di configurazione del cluster.

• Accesso all'API Kubernetes.

  Questo livello di accesso è controllato da:

  • Controllo degli accessi in base al ruolo di Kubernetes (tradizionalmente) o
  • Integrando il controllo degli accessi in base al ruolo di Azure con il servizio Azure Kubernetes per l'autorizzazione di kubernetes.

  Per informazioni su come concedere in modo granulare le autorizzazioni all'API Kubernetes usando il controllo degli accessi in base al ruolo di Azure, vedere Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione di Kubernetes.

Usare le identità gestite da pod

Non usare credenziali fisse all'interno dei pod o delle immagini del contenitore, poiché sono a rischio di esposizione o uso improprio. In alternativa, usare le identità dei pod per richiedere automaticamente l'accesso tramite Microsoft Entra ID.

Per accedere ad altre risorse di Azure, ad esempio Azure Cosmos DB, Key Vault o Archiviazione BLOB, il pod necessita di credenziali di autenticazione. È possibile definire le credenziali di autenticazione con l'immagine del contenitore o inserirle come un segreto di Kubernetes. In entrambi i casi, sarà necessario crearle e assegnarle manualmente. In genere, le credenziali vengono riutilizzate nei pod e non vengono ruotate regolarmente.

Con le identità gestite da pod (anteprima) per le risorse di Azure, richiedere automaticamente l'accesso ai servizi tramite Microsoft Entra ID. Le identità gestite da pod sono attualmente in anteprima per il servizio Azure Kubernetes. Per iniziare, vedere la documentazione Usare le identità gestite da pod di Microsoft Entra nel servizio Azure Kubernetes (anteprima).

L'identità gestita da pod di Microsoft Entra (anteprima) supporta due modalità di funzionamento:

• Modalità standard: in questa modalità i 2 componenti seguenti vengono distribuiti nel cluster del servizio Azure Kubernetes:

  • Controller identità gestita (MIC): un controller Kubernetes che controlla le modifiche apportate ai pod, AzureIdentity e AzureIdentityBinding tramite il server API di Kubernetes. Quando rileva una modifica pertinente, il MIC aggiunge o elimina AzureAssignedIdentity in base alle esigenze. In particolare, quando viene pianificato un pod, MIC assegna l'identità gestita in Azure al set di scalabilità di macchine virtuali sottostante usato dal pool di nodi durante la fase di creazione. Quando tutti i pod che usano l'identità vengono eliminati, rimuove l'identità dal set di scalabilità di macchine virtuali del pool di nodi, a meno che la stessa identità gestita non venga usata da altri pod. Il MIC esegue azioni simili quando AzureIdentity o AzureIdentityBinding vengono creati o eliminati.

  • Identità gestita del nodo (NMI) è un pod che viene eseguito come DaemonSet su ogni nodo nel cluster del servizio Azure Kubernetes. NMI intercetta le richieste di token di sicurezza al servizio metadati dell'istanza di Azure in ogni nodo. Reindirizza le richieste a se stesso e convalida se il pod ha accesso all'identità per cui sta richiedendo un token e recupera il token dal tenant di Microsoft Entra per conto dell'applicazione.

• Modalità gestita: in questa modalità è disponibile solo NMI. L'identità deve essere assegnata e gestita manualmente dall'utente. Per altre informazioni, vedere Identità pod in modalità gestita. In questa modalità, quando si usa il comando az aks pod-identity add per aggiungere un'identità pod a un cluster del servizio Azure Kubernetes (AKS), vengono create le risorse AzureIdentity e AzureIdentityBinding nello spazio dei nomi specificato dal parametro --namespace, mentre il provider di risorse del servizio Azure Kubernetes assegna l'identità gestita specificata dal parametro --identity-resource-id al set di scalabilità di macchine virtuali di ogni pool di nodi nel cluster del servizio Azure Kubernetes.

La modalità managed offre i vantaggi seguenti rispetto alla modalità standard:

• L'assegnazione di identità nel set di scalabilità di macchine virtuali di un pool di nodi può richiedere fino a 40-60 anni. Con cronjob o applicazioni che richiedono l'accesso all'identità e non possono tollerare il ritardo di assegnazione, è consigliabile usare la modalità managed perché l'identità è pre-assegnata al set di scalabilità di macchine virtuali del pool di nodi. Sia manualmente che usando il comando az aks pod-identity add.
• In modalità standard, MIC richiede autorizzazioni di scrittura per il set di scalabilità di macchine virtuali usato dal cluster del servizio Azure Kubernetes e l'autorizzazione Managed Identity Operator per le identità gestite assegnate dall'utente. Durante l'esecuzione in managed mode, poiché non è presente un MIC, le assegnazioni di ruolo non sono necessarie.

Anziché definire manualmente le credenziali per i pod, le identità gestite da pod richiedono un token di accesso in tempo reale, che usano per accedere solo alle risorse assegnate. Nel servizio Azure Kubernetes sono disponibili due componenti che gestiscono le operazioni per consentire ai pod di usare le identità gestite:

• Il server NMI (Node Management Identity) è un pod che viene eseguito come DaemonSet su ogni nodo nel cluster servizio Azure Kubernetes. Il server NMI ascolta le richieste del pod ai servizi di Azure.
• Il provider di risorse di Azure esegue una query sul server API Kubernetes e verifica la presenza di un mapping delle identità di Azure corrispondente a un pod.

Quando i pod richiedono un token di sicurezza da Microsoft Entra ID per accedere a una risorsa di Azure, le regole di rete reindirizzano il traffico al server NMI.

1. Il server NMI:

   • Identifica i pod che richiedono l'accesso alle risorse di Azure in base al relativo indirizzo remoto.
   • Esegue una query sul provider di risorse di Azure.

2. Il provider di risorse di Azure verifica la presenza di mapping delle identità di Azure nel cluster del servizio Azure Kubernetes.

3. Il server NMI richiede un token di accesso da Microsoft Entra ID in base al mapping delle identità del pod.

4. Microsoft Entra ID fornisce l'accesso al server NMI, che viene restituito al pod.

   • Questo token di accesso può essere quindi usato dal pod per richiedere l'accesso alle risorse in Azure.

Nell'esempio seguente uno sviluppatore crea un pod che usa un'identità gestita per richiedere l'accesso a un database SQL di Azure:

1. L'operatore del cluster crea un account del servizio per eseguire il mapping delle identità quando i pod richiedono l'accesso alle risorse.
2. Il server NMI viene distribuito per inoltrare le richieste di pod, insieme al provider di risorse di Azure, per i token di accesso a Microsoft Entra ID.
3. Uno sviluppatore distribuisce un pod con un'identità gestita che richiede un token di accesso tramite il server NMI.
4. Il token viene restituito al pod e usato per accedere a un database SQL di Azure

Per usare le identità gestite da pod, vedere Usare le identità gestite da pod di Microsoft Entra nel servizio Azure Kubernetes (anteprima).

Passaggi successivi

Questo articolo sulle procedure consigliate ha illustrato l'autenticazione e l'autorizzazione per il cluster e le risorse. Per implementare alcune di queste procedure consigliate, vedere gli articoli seguenti:

• Integrare Microsoft Entra ID con il servizio Azure Kubernetes
• Usare le identità gestite da pod di Microsoft Entra nel servizio Azure Kubernetes (anteprima)

Per altre informazioni sulle operazioni cluster in servizio Azure Kubernetes, vedere le procedure consigliate seguenti:

• Isolamento cluster e multi-tenant
• Funzionalità di base dell'utilità di pianificazione di Kubernetes
• Funzionalità avanzate dell'utilità di pianificazione di Kubernetes