Usare un'identità gestita in servizio Azure Kubernetes (servizio Azure Kubernetes)

I cluster servizio Azure Kubernetes (servizio Azure Kubernetes) richiedono un'identità per accedere alle risorse di Azure, ad esempio i servizi di bilanciamento del carico e i dischi gestiti. L'identità può essere un'identità gestita o un'entità servizio.

Questo articolo fornisce informazioni dettagliate su come abilitare i tipi di identità gestiti seguenti in un cluster del servizio Azure Kubernetes nuovo o esistente:

• Identità gestita assegnata dal sistema
• Bring your own user-assigned managed identity (Bring Your Own User-Assigned Managed Identity)
• Identità gestita Kubelet creata in modo preliminare

Panoramica

Quando si distribuisce un cluster del servizio Azure Kubernetes, viene creata automaticamente un'identità gestita assegnata dal sistema e gestita dalla piattaforma Azure, quindi non è necessario effettuare il provisioning o ruotare i segreti. Per altre informazioni, vedere Identità gestite per le risorse di Azure.

Il servizio Azure Kubernetes non crea automaticamente un'entità servizio, quindi è necessario crearne una. I cluster che usano un'entità servizio alla fine scadono e l'entità servizio deve essere rinnovata per evitare di influire sull'autenticazione del cluster con l'identità. La gestione delle entità servizio aggiunge complessità, quindi è più facile usare le identità gestite. Gli stessi requisiti di autorizzazione si applicano sia alle entità servizio che alle identità gestite. Le identità gestite usano l'autenticazione basata su certificati. Le credenziali di ogni identità gestita hanno una scadenza di 90 giorni e vengono implementate 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. Questi tipi di identità non devono essere confusi con un'identità del carico di lavoro Microsoft Entra, destinata all'uso da parte di un'applicazione in esecuzione in un pod.

Importante

L'identità gestita dal pod microsoft Entra open source (anteprima) in servizio Azure Kubernetes è stata deprecata il 10/24/2022 e il progetto archiviato nel settembre 2023. Per altre informazioni, vedere l'avviso di deprecazione. Il componente aggiuntivo gestito del servizio Azure Kubernetes inizia la deprecazione a settembre 2024.

È consigliabile esaminare prima ID dei carichi di lavoro di Microsoft Entra panoramica. Entra ID dei carichi di lavoro'autenticazione sostituisce l'identità gestita dal pod di Microsoft Entra (anteprima) ed è il metodo consigliato per consentire a un'applicazione in esecuzione in un pod di autenticarsi con altri servizi di Azure che lo supportano.

Operazioni preliminari

• Assicurarsi di avere installato l'interfaccia della riga di comando di Azure versione 2.23.0 o successiva. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

• Per usare un'identità gestita kubelet già creata, è necessaria l'interfaccia della riga di comando di Azure versione 2.26.0 o successiva installata.

• Per aggiornare l'identità gestita in un cluster esistente, è necessaria l'interfaccia della riga di comando di Azure versione 2.49.0 o successiva installata.

Limiti

• Lo spostamento o la migrazione di un cluster abilitato per le identità gestite non è supportato.
• Se nel cluster è abilitata l'identità gestita dal pod di Microsoft Entra (aad-pod-identity), i pod di identità gestita dal nodo modificano le tabelle iptable dei nodi per intercettare le chiamate all'endpoint IMDS (Azure Instance Metadata). Questa configurazione significa che qualsiasi richiesta effettuata all'endpoint metadati viene intercettata da NMI, anche se il pod non usa aad-pod-identity. AzurePodIdentityException CRD può essere configurato per informare aad-pod-identity eventuali richieste all'endpoint dei metadati provenienti da un pod che corrisponde alle etichette definite in CRD deve essere sottoposto a proxy senza alcuna elaborazione in NMI. I pod di sistema con kubernetes.azure.com/managedby: aks etichetta nello spazio dei nomi kube-system devono essere esclusi aad-pod-identity tramite la configurazione di AzurePodIdentityException CRD.
  • Per altre informazioni, vedere Disabilitare Microsoft Entra ID-pod-identity per un pod o un'applicazione specifica.
  • Per configurare un'eccezione, installare mic-exception YAML.
• Il servizio Azure Kubernetes non supporta l'uso di un'identità gestita assegnata dal sistema quando si usa una zona DNS privata personalizzata.

Riepilogo delle identità gestite

Il servizio Azure Kubernetes usa diverse identità gestite per i servizi e i componenti aggiuntivi predefiniti.

Identità	Nome	Caso d'uso	Autorizzazioni predefinite	Bring Your Own Identity
Piano di controllo	Nome del cluster del servizio Azure Kubernetes	Usato dai componenti del piano di controllo del servizio Azure Kubernetes per gestire 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, il disco di Azure, il file, i driver CSI BLOB.	Ruolo collaboratore per il gruppo di risorse Node	Supportata
Kubelet	Nome del cluster del servizio Azure Kubernetes -agentpool	Autenticazione con Registro Azure Container (ACR).	N/D (per kubernetes v1.15+)	Supportata
Componente aggiuntivo	AzureNPM	Nessuna identità necessaria.	N/D	No
Componente aggiuntivo	Monitoraggio di rete di AzureCNI	Nessuna identità necessaria.	N/D	No
Componente aggiuntivo	azure-policy (gatekeeper)	Nessuna identità necessaria.	N/D	No
Componente aggiuntivo	azure-policy	Nessuna identità necessaria.	N/D	No
Componente aggiuntivo	Calico	Nessuna identità necessaria.	N/D	No
Componente aggiuntivo	Dashboard	Nessuna identità necessaria.	N/D	No
Componente aggiuntivo	application-routing	Gestisce i certificati DNS di Azure e Azure Key Vault	Ruolo utente dei segreti dell'insieme di credenziali delle chiavi per Key Vault, ruolo Collaboratore zona DNZ per le zone DNS, ruolo Collaboratore zona DNS privato per le zone DNS private	No
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	Usato per inviare le metriche del servizio Azure Kubernetes a Monitoraggio di Azure.	Ruolo del server di pubblicazione delle metriche di monitoraggio	No
Componente aggiuntivo	Virtual-Node (ACI Connessione or)	Gestisce le risorse di rete necessarie per Istanze di Azure Container (ACI).	Ruolo collaboratore per il gruppo di risorse del nodo	No
Componente aggiuntivo	Analisi dei costi	Usato per raccogliere i dati di allocazione dei costi
Identità del carico di lavoro	ID carico di lavoro Microsoft Entra	Consente alle applicazioni di accedere in modo sicuro alle risorse cloud con l'ID del carico di lavoro Microsoft Entra.	N/D	No

Abilitare le identità gestite in un nuovo cluster del servizio Azure Kubernetes

Nota

Il servizio Azure Kubelet crea un'identità kubelet assegnata dall'utente nel gruppo di risorse del nodo se non si specifica la propria identità gestita kubelet.

Nota

Se il cluster usa già l'identità gestita e l'identità è stata modificata, ad esempio si aggiorna il tipo di identità del cluster da assegnato al sistema assegnato all'utente, si verifica un ritardo per i componenti del piano di controllo per passare alla nuova identità. I componenti del piano di controllo continuano a usare l'identità precedente fino alla scadenza del token. Dopo l'aggiornamento del token, passano alla nuova identità. Questo processo può richiedere diverse ore.

1. Creare un gruppo di risorse di Azure usando il az group create comando .

   az group create --name myResourceGroup --location westus2
   

2. Creare un cluster del servizio Azure Kubernetes usando il comando az aks create.

   az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity
   

3. Ottenere le credenziali per accedere al cluster usando il az aks get-credentials comando .

   az aks get-credentials --resource-group myResourceGroup --name myManagedCluster
   

Abilitare le identità gestite in un cluster del servizio Azure Kubernetes esistente

Per aggiornare il cluster del servizio Azure Kubernetes esistente che usa un'entità servizio per usare un'identità gestita assegnata dal sistema, eseguire il az aks update comando .

az aks update -g myResourceGroup -n myManagedCluster --enable-managed-identity

Dopo l'aggiornamento del cluster, il piano di controllo e i pod usano l'identità gestita. Kubelet continua a usare un'entità servizio fino a quando non si aggiorna il pool di agenti. È possibile usare il comando nei az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only nodi per eseguire l'aggiornamento a un'identità gestita. Un aggiornamento del pool di nodi causa tempi di inattività per il cluster del servizio Azure Kubernetes perché i nodi nei pool di nodi vengono bloccato/svuotato e ricreato l'immagine.

Nota

Quando si aggiorna il cluster, tenere presenti le informazioni seguenti:

• Un aggiornamento funziona solo se è disponibile un aggiornamento del disco rigido virtuale da utilizzare. Se si esegue il disco rigido virtuale più recente, è necessario attendere che il disco rigido virtuale successivo sia disponibile per eseguire l'aggiornamento.

• L'interfaccia della riga di comando di Azure garantisce che l'autorizzazione del componente aggiuntivo sia impostata correttamente dopo la migrazione. Se non si usa l'interfaccia della riga di comando di Azure per eseguire l'operazione di migrazione, è necessario gestire manualmente l'autorizzazione dell'identità del componente aggiuntivo. Per un esempio di uso di un modello di Azure Resource Manager (ARM), vedere Assegnare ruoli di Azure usando i modelli di Resource Manager.

• Se il cluster usava --attach-acr per eseguire il pull da immagini da Registro Azure Container, è necessario eseguire il az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR resource ID> comando dopo l'aggiornamento del cluster per consentire al kubelet appena creato usato per l'identità gestita di ottenere l'autorizzazione per eseguire il pull da Registro Azure Container. In caso contrario, non sarà possibile eseguire il pull da Registro Azure Container dopo l'aggiornamento.

Aggiungere un'assegnazione di ruolo per l'identità gestita

Quando si crea e si usa la propria rete virtuale, collegare dischi di Azure, indirizzo IP statico, tabella di route o identità kubelet assegnata dall'utente in cui le risorse si trovano all'esterno del gruppo di risorse del nodo di lavoro, l'interfaccia della riga di comando di Azure aggiunge automaticamente l'assegnazione di ruolo. Se si usa un modello arm o un altro metodo, è necessario usare l'ID entità dell'identità gestita del cluster per eseguire un'assegnazione di ruolo.

Se non si usa l'interfaccia della riga di comando di Azure, ma si usa la propria rete virtuale, collegare dischi di Azure, indirizzo IP statico, tabella di route o identità kubelet assegnata dall'utente all'esterno del gruppo di risorse del nodo di lavoro, è consigliabile usare l'identità gestita assegnata dall'utente per il piano di controllo. Per consentire al piano di controllo di usare un'identità gestita assegnata dal sistema, non è possibile ottenere l'ID identità prima di creare il cluster, che ritarda l'assegnazione di ruolo.

Ottenere l'ID principale dell'identità gestita

• Ottenere l'ID entità dell'identità esistente usando il az identity show comando .

  az identity show --ids <identity-resource-id>
  

  L'output dovrebbe essere simile all'output di esempio seguente:

  {
    "clientId": "<client-id>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",
    "location": "eastus",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

Aggiungi un'assegnazione di ruolo

Per una rete virtuale, un disco di Azure collegato, un indirizzo IP statico o una tabella di route all'esterno del gruppo di risorse del nodo di lavoro predefinito, è necessario assegnare il Contributor ruolo nel gruppo di risorse personalizzato.

• Assegnare il Contributor ruolo nel gruppo di risorse personalizzato usando il az role assignment create comando .

  az role assignment create --assignee <control-plane-identity-principal-id> --role "Contributor" --scope "<custom-resource-group-resource-id>"
  

Per un'identità kubelet assegnata dall'utente all'esterno del gruppo di risorse del nodo di lavoro predefinito, è necessario assegnare il ruolo Operatore identità gestita nell'identità kubelet per l'identità gestita del piano di controllo.

• Assegnare il Managed Identity Operator ruolo nell'identità kubelet usando il az role assignment create comando .

  az role assignment create --assignee  <control-plane-identity-principal-id> --role "Managed Identity Operator" --scope "<kubelet-identity-resource-id>"
  

Nota

Il popolamento delle autorizzazioni concesse all'identità gestita del cluster può richiedere fino a 60 minuti.

Bring Your Own Managed Identity

Creare un cluster usando l'identità gestita assegnata dall'utente

Un'identità gestita assegnata dall'utente personalizzata per il piano di controllo consente l'accesso all'identità esistente prima della creazione del cluster. Questa funzionalità abilita scenari come l'uso di una rete virtuale personalizzata o un outboundType di route definita dall'utente con un'identità gestita creata in anteprima.

Nota

Le aree di USDOD Central, USDOD East e USGov Iowa nel cloud di Azure US Government non sono supportate.

Il servizio Azure Kubelet crea un'identità kubelet assegnata dall'utente nel gruppo di risorse del nodo se non si specifica la propria identità gestita kubelet.

• Se non si ha un'identità gestita, crearne una usando il az identity create comando .

  az identity create --name myIdentity --resource-group myResourceGroup
  

  L'output dovrebbe essere simile all'output di esempio seguente:

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

Nota

Il popolamento delle autorizzazioni concesse all'identità gestita del cluster può richiedere fino a 60 minuti.

• Prima di creare il cluster, aggiungere l'assegnazione di ruolo per l'identità gestita usando il az role assignment create comando .

• Creare il cluster con l'identità gestita assegnata dall'utente.

  az aks create \
      --resource-group myResourceGroup \
      --name myManagedCluster \
      --network-plugin azure \
      --vnet-subnet-id <subnet-id> \
      --dns-service-ip 10.2.0.10 \
      --service-cidr 10.2.0.0/24 \
      --enable-managed-identity \
      --assign-identity <identity-resource-id>
  

Aggiornare l'identità gestita in un cluster esistente

Nota

La migrazione di un'identità gestita per il piano di controllo, assegnata dal sistema all'utente, non causa tempi di inattività per il piano di controllo e i pool di agenti. Nel frattempo, i componenti del piano di controllo continuano a usare l'identità assegnata dal sistema precedente per diverse ore fino al successivo aggiornamento del token.

• Se non si ha un'identità gestita, crearne una usando il az identity create comando .

  az identity create --name myIdentity --resource-group myResourceGroup
  

  L'output dovrebbe essere simile all'output di esempio seguente:

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

• Dopo aver creato l'identità gestita assegnata dall'utente personalizzata per il piano di controllo, aggiungere l'assegnazione di ruolo per l'identità gestita usando il az role assignment create comando .

• Aggiornare il cluster con le identità esistenti usando il az aks update comando . Assicurarsi di specificare l'ID risorsa dell'identità gestita per il piano di controllo includendo l'argomento assign-identity .

  az aks update \
      --resource-group myResourceGroup \
      --name myManagedCluster \
      --enable-managed-identity \
      --assign-identity <identity-resource-id> 
  

  L'output per un aggiornamento corretto del cluster usando la propria identità gestita kubelet dovrebbe essere simile all'output di esempio seguente:

    "identity": {
      "principalId": null,
      "tenantId": null,
      "type": "UserAssigned",
      "userAssignedIdentities": {
        "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
          "clientId": "<client-id>",
          "principalId": "<principal-id>"
        }
      }
    },
  

Usare un'identità gestita kubelet creata in modo preliminare

Un'identità kubelet consente l'accesso all'identità esistente prima della creazione del cluster. Questa funzionalità abilita scenari come la connessione al Registro Azure Container con un'identità gestita creata in anteprima.

Limitazioni dell'identità kubelet create in anteprima

• Funziona solo con un cluster gestito assegnato dall'utente.
• Le aree Cina orientale e Cina settentrionale in Microsoft Azure gestite da 21Vianet non sono supportate.

Creare identità gestite assegnate dall'utente

Identità gestita del piano di controllo

• Se non si dispone di un'identità gestita per il piano di controllo, crearne una usando .az identity create

  az identity create --name myIdentity --resource-group myResourceGroup
  

  L'output dovrebbe essere simile all'output di esempio seguente:

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

Identità gestita kubelet

• Se non si ha un'identità gestita kubelet, crearne una usando il az identity create comando .

  az identity create --name myKubeletIdentity --resource-group myResourceGroup
  

  L'output dovrebbe essere simile all'output di esempio seguente:

  {
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity", 
    "location": "westus2",
    "name": "myKubeletIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

Creare un cluster usando l'identità kubelet assegnata dall'utente

È ora possibile creare il cluster del servizio Azure Kubernetes con le identità esistenti. Assicurarsi di specificare l'ID risorsa dell'identità gestita per il piano di controllo includendo l'argomento assign-identity e l'identità gestita kubelet usando l'argomento assign-kubelet-identity .

• Creare un cluster del servizio Azure Kubernetes con le identità esistenti usando il az aks create comando .

  az aks create \
      --resource-group myResourceGroup \
      --name myManagedCluster \
      --network-plugin azure \
      --vnet-subnet-id <subnet-id> \
      --dns-service-ip 10.2.0.10 \
      --service-cidr 10.2.0.0/24 \
      --enable-managed-identity \
      --assign-identity <identity-resource-id> \
      --assign-kubelet-identity <kubelet-identity-resource-id>
  

  Una creazione corretta del cluster del servizio Azure Kubelet usando un'identità gestita kubelet dovrebbe essere simile all'output di esempio seguente:

    "identity": {
      "principalId": null,
      "tenantId": null,
      "type": "UserAssigned",
      "userAssignedIdentities": {
        "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
          "clientId": "<client-id>",
          "principalId": "<principal-id>"
        }
      }
    },
    "identityProfile": {
      "kubeletidentity": {
        "clientId": "<client-id>",
        "objectId": "<object-id>",
        "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity"
      }
    },
  

Aggiornare un cluster esistente usando l'identità kubelet

Avviso

L'aggiornamento dei pool di nodi dell'identità gestita kubelet consente di aggiornare i pool di nodi, causando tempi di inattività per il cluster del servizio Azure Kubernetes man mano che i nodi nei pool di nodi vengono bloccato/svuotato e ricreato l'immagine.

Nota

Se il cluster usava --attach-acr per eseguire il pull da immagini da Registro Azure Container, è necessario eseguire il az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR Resource ID> comando dopo l'aggiornamento del cluster per consentire al kubelet appena creato usato per l'identità gestita di ottenere l'autorizzazione per eseguire il pull da Registro Azure Container. In caso contrario, non sarà possibile eseguire il pull da Registro Azure Container dopo l'aggiornamento.

Ottenere l'identità gestita del piano di controllo corrente per il cluster del servizio Azure Kubernetes

1. Verificare che il cluster del servizio Azure Kubernetes usi l'identità gestita assegnata dall'utente usando il az aks show comando .

   az aks show -g <RGName> -n <ClusterName> --query "servicePrincipalProfile"
   

   Se il cluster usa un'identità gestita, l'output viene visualizzato clientId con un valore msi. Un cluster che usa un'entità servizio mostra un ID oggetto. Ad esempio:

   {
     "clientId": "msi"
   }
   

2. Dopo aver confermato che il cluster usa un'identità gestita, trovare l'ID risorsa dell'identità gestita usando il az aks show comando .

   az aks show -g <RGName> -n <ClusterName> --query "identity"
   

   Per un'identità gestita assegnata dall'utente, l'output dovrebbe essere simile all'output di esempio seguente:

   {
     "principalId": null,
     "tenantId": null,
     "type": "UserAssigned",
     "userAssignedIdentities": <identity-resource-id>
         "clientId": "<client-id>",
         "principalId": "<principal-id>"
   },
   

Aggiornare il cluster con l'identità kubelet

1. Se non si ha un'identità gestita kubelet, crearne una usando il az identity create comando .

   az identity create --name myKubeletIdentity --resource-group myResourceGroup
   

   L'output dovrebbe essere simile all'output di esempio seguente:

   {
     "clientId": "<client-id>",
     "clientSecretUrl": "<clientSecretUrl>",
     "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity",
     "location": "westus2",
     "name": "myKubeletIdentity",
     "principalId": "<principal-id>",
     "resourceGroup": "myResourceGroup",                       
     "tags": {},
     "tenantId": "<tenant-id>",
     "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
   }
   

2. Aggiornare il cluster con le identità esistenti usando il az aks update comando . Assicurarsi di specificare l'ID risorsa dell'identità gestita per il piano di controllo includendo l'argomento e l'identità assign-identity gestita kubelet per assign-kubelet-identity l'argomento.

   az aks update \
       --resource-group myResourceGroup \
       --name myManagedCluster \
       --enable-managed-identity \
       --assign-identity <identity-resource-id> \
       --assign-kubelet-identity <kubelet-identity-resource-id>
   

   L'output per un aggiornamento corretto del cluster usando la propria identità gestita kubelet dovrebbe essere simile all'output di esempio seguente:

     "identity": {
       "principalId": null,
       "tenantId": null,
       "type": "UserAssigned",
       "userAssignedIdentities": {
         "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity": {
           "clientId": "<client-id>",
           "principalId": "<principal-id>"
         }
       }
     },
     "identityProfile": {
       "kubeletidentity": {
         "clientId": "<client-id>",
         "objectId": "<object-id>",
         "resourceId": "/subscriptions/<subscriptionid>/resourcegroups/resourcegroups/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity"
       }
     },
   

Passaggi successivi

• Usare i modelli di Azure Resource Manager per creare un cluster abilitato per l'identità gestita.
• Informazioni su come [usare kubelogin][kubelogin-authentication] per tutti i metodi di autenticazione di Microsoft Entra supportati nel servizio Azure Kubernetes.