Condividi tramite

Usare un'identità gestita nel servizio Azure Kubernetes.

  • Articolo

I cluster servizio Azure Kubernetes (servizio Azure Kubernetes) richiedono un'identità Di Microsoft Entra per accedere alle risorse di Azure, ad esempio i servizi di bilanciamento del carico e i dischi gestiti. Le identità gestite per le risorse di Azure sono il modo consigliato per autorizzare l'accesso da un cluster del servizio Azure Kubernetes ad altri servizi di Azure.

È possibile usare un'identità gestita per autorizzare l'accesso da un cluster del servizio Azure Kubernetes a qualsiasi servizio che supporta l'autorizzazione di Microsoft Entra, senza dover gestire le credenziali o includerle nel codice. Si assegna all'identità gestita un ruolo di controllo degli accessi in base al ruolo di Azure per concedere le autorizzazioni a una determinata risorsa in Azure. Ad esempio, è possibile concedere autorizzazioni a un'identità gestita per accedere ai segreti in un insieme di credenziali delle chiavi di Azure da usare dal cluster. Per ulteriori informazioni sul controllo degli accessi in base al ruolo di Azure, vedere Che cos'è il controllo degli accessi in base al ruolo di Azure?.

Questo articolo illustra come abilitare i tipi di identità gestita seguenti in un cluster del servizio Azure Kubernetes nuovo o esistente:

  • Identità gestita assegnata dal sistema. 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.
  • Identità gestita assegnata dall'utente. Un'identità gestita assegnata dall'utente è una risorsa di Azure autonoma che un cluster del servizio Azure Kubernetes può usare per autorizzare l'accesso ad altri servizi di Azure. Viene mantenuta separatamente dal cluster del servizio Azure Kubernetes e può essere usata da più risorse di Azure.
  • Identità gestita kubelet creata in modo preliminare. Un'identità gestita kubelet creata in modo preliminare è un'identità assegnata dall'utente facoltativa che kubelet può usare per accedere ad altre risorse in Azure. Se non si specifica un'identità gestita assegnata dall'utente per kubelet, il servizio Azure Kubernetes crea un'identità kubelet assegnata dal sistema nel gruppo di risorse del nodo.

Per altre informazioni sulle identità gestite, vedere Identità gestite per le risorse di Azure.

Panoramica

Un cluster del servizio Azure Kubernetes usa un'identità gestita per richiedere token da Microsoft Entra. Questi token vengono usati per autorizzare l'accesso ad altre risorse in esecuzione in Azure. È possibile assegnare un ruolo controllo degli accessi in base al ruolo di Azure a un'identità gestita per concedere al cluster le autorizzazioni per accedere a risorse specifiche. Ad esempio, se il cluster deve accedere ai segreti in un insieme di credenziali delle chiavi di Azure, è possibile assegnare all'identità gestita del cluster un ruolo controllo degli accessi in base al ruolo di Azure che concede tali autorizzazioni.

Un'identità gestita può essere assegnata dal sistema o assegnata dall'utente. Questi due tipi di identità gestite sono simili in quanto è possibile usare entrambi i tipi per autorizzare l'accesso alle risorse di Azure dal cluster del servizio Azure Kubernetes. La differenza principale tra di esse è che un'identità gestita assegnata dal sistema è associata a una singola risorsa di Azure, ad esempio un cluster del servizio Azure Kubernetes, mentre un'identità gestita assegnata dall'utente è una risorsa di Azure autonoma. Per altre informazioni sulle differenze tra i tipi di identità gestite, vedere Tipi di identità gestite in Identità gestite per le risorse di Azure.

Entrambi i tipi di identità gestite vengono gestiti dalla piattaforma Azure, in modo da poter autorizzare l'accesso dalle applicazioni senza dover effettuare il provisioning o ruotare i segreti. Azure gestisce automaticamente le credenziali dell'identità.

Quando si distribuisce un cluster del servizio Azure Kubernetes, per impostazione predefinita viene creata un'identità gestita assegnata dal sistema. È anche possibile creare il cluster con un'identità gestita assegnata dall'utente.

È anche possibile creare un cluster con un'entità servizio dell'applicazione anziché un'identità gestita. Le identità gestite sono consigliate rispetto alle entità servizio per la sicurezza e la facilità d'uso. Per altre informazioni sulla creazione di un cluster con un'entità servizio, vedere Usare un'entità servizio con servizio Azure Kubernetes (servizio Azure Kubernetes).

È possibile aggiornare un cluster esistente per usare un'identità gestita da un'entità servizio dell'applicazione. È anche possibile aggiornare un cluster esistente a un tipo diverso di identità gestita. Se il cluster usa già un'identità gestita e l'identità è stata modificata, ad esempio se il tipo di identità del cluster è stato aggiornato dal sistema assegnato all'utente, si verifica un ritardo mentre i componenti del piano di controllo passano 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 alcune ore.

I tipi di identità assegnati dal sistema e assegnati dall'utente differiscono da un'identità del carico di lavoro Microsoft Entra, destinata all'uso da parte di un'applicazione in esecuzione in un pod.

Operazioni preliminari

Prima di eseguire gli esempi in questo articolo, impostare la sottoscrizione come sottoscrizione attiva corrente chiamando il comando az account set e passando l'ID sottoscrizione.

az account set --subscription <subscription-id>

Creare anche un gruppo di risorse di Azure se non ne è già disponibile uno chiamando il az group create comando .

az group create \
    --name myResourceGroup \
    --location westus2

Abilitare un'identità gestita assegnata dal sistema

Un'identità gestita assegnata dal sistema è un'identità associata a un cluster del servizio Azure Kubernetes o a un'altra risorsa di Azure. L'identità gestita assegnata dal sistema è associata al ciclo di vita del cluster. Quando il cluster viene eliminato, viene eliminata anche l'identità gestita assegnata dal sistema.

Il cluster del servizio Azure Kubernetes può usare l'identità gestita assegnata dal sistema per autorizzare l'accesso ad altre risorse in esecuzione in Azure. È possibile assegnare un ruolo controllo degli accessi in base al ruolo di Azure all'identità gestita assegnata dal sistema per concedere al cluster le autorizzazioni per accedere a risorse specifiche. Ad esempio, se il cluster deve accedere ai segreti in un insieme di credenziali delle chiavi di Azure, è possibile assegnare all'identità gestita assegnata dal sistema un ruolo controllo degli accessi in base al ruolo di Azure che concede tali autorizzazioni.

Abilitare un'identità gestita assegnata dal sistema in un nuovo cluster del servizio Azure Kubernetes

Per abilitare un'identità gestita assegnata dal sistema in un nuovo cluster, chiamare .az aks create Per impostazione predefinita, nel nuovo cluster è abilitata un'identità gestita assegnata dal sistema.

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

az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --generate-ssh-keys

Per verificare che un'identità gestita assegnata dal sistema sia abilitata per il cluster dopo la creazione, vedere Determinare quale tipo di identità gestita usa un cluster.

Aggiornare un cluster del servizio Azure Kubernetes esistente per usare un'identità gestita assegnata dal sistema

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

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity

Dopo aver aggiornato il cluster per usare un'identità gestita assegnata dal sistema anziché un'entità servizio, il piano di controllo e i pod usano l'identità gestita assegnata dal sistema per l'autorizzazione quando accedono ad altri servizi in Azure. Kubelet continua a usare un'entità servizio fino a quando non si aggiorna anche il pool di agenti. È possibile usare il comando az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only nei 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 dalle immagini da Registro Azure Container (ACR), è 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 un'identità gestita assegnata dal sistema

È possibile assegnare un ruolo controllo degli accessi in base al ruolo di Azure all'identità gestita assegnata dal sistema per concedere le autorizzazioni del cluster in un'altra risorsa di Azure. Il controllo degli accessi in base al ruolo di Azure supporta definizioni di ruolo predefinite e personalizzate che specificano i livelli di autorizzazioni. Per altre informazioni sull'assegnazione dei ruoli controllo degli accessi in base al ruolo di Azure, vedere Passaggi per assegnare un ruolo di Azure.

Quando si assegna un ruolo controllo degli accessi in base al ruolo di Azure a un'identità gestita, è necessario definire l'ambito per il ruolo. In generale, è consigliabile limitare l'ambito di un ruolo ai privilegi minimi richiesti dall'identità gestita. Per altre informazioni sull'ambito dei ruoli controllo degli accessi in base al ruolo di Azure, vedere Comprendere l'ambito per il controllo degli accessi in base al ruolo di Azure.

Quando si crea e si usa la propria rete virtuale, i dischi di Azure collegati, l'indirizzo IP statico, la tabella di route o l'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 di Resource Manager o un altro metodo, usare l'ID entità dell'identità gestita 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, i dischi di Azure collegati, l'indirizzo IP statico, la tabella di route o l'identità kubelet assegnata dall'utente all'esterno del gruppo di risorse del nodo di lavoro, è consigliabile usare un'identità gestita assegnata dall'utente per il piano di controllo. Quando il piano di controllo usa un'identità gestita assegnata dal sistema, l'identità viene creata contemporaneamente al cluster, quindi l'assegnazione di ruolo non può essere eseguita fino a quando non viene creato il cluster.

Ottenere l'ID entità dell'identità gestita assegnata dal sistema

Per assegnare un ruolo controllo degli accessi in base al ruolo di Azure all'identità gestita assegnata dal sistema di un cluster, è necessario innanzitutto l'ID entità per l'identità gestita. Ottenere l'ID entità per l'identità gestita assegnata dal sistema del cluster chiamando il az aks show comando .

# Get the principal ID for a system-assigned managed identity.
CLIENT_ID=$(az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.principalId \
    --output tsv)

Assegnare un ruolo controllo degli accessi in base al ruolo di Azure all'identità gestita assegnata dal sistema

Per concedere autorizzazioni di identità gestita assegnate dal sistema a una risorsa in Azure, chiamare il az role assignment create comando per assegnare un ruolo controllo degli accessi in base al ruolo di Azure all'identità gestita.

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 ruolo di Contributor nel gruppo di risorse personalizzato.

Ad esempio, assegnare il Contributor ruolo nel gruppo di risorse personalizzato usando il az role assignment create comando . Per il --scope parametro specificare l'ID risorsa per il gruppo di risorse per il cluster.

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Contributor" \
    --scope "<resource-group-id>"

Nota

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

Abilitare un'identità gestita assegnata dall'utente

Un'identità gestita assegnata dall'utente è una risorsa di Azure autonoma. Quando si crea un cluster con un'identità gestita assegnata dall'utente per il piano di controllo, la risorsa di identità gestita assegnata dall'utente deve esistere prima della creazione del cluster. Questa funzionalità abilita scenari come la creazione del cluster con una rete virtuale personalizzata o con un tipo in uscita di routing definito dall'utente.

Creare un'identità gestita assegnata dall'utente

Se non si ha ancora una risorsa di identità gestita assegnata dall'utente, 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"
}

Ottenere l'ID entità dell'identità gestita assegnata dall'utente

Per ottenere l'ID entità dell'identità gestita assegnata dall'utente, chiamare az identity show ed eseguire una query sulla principalId proprietà :

CLIENT_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query principalId \
    --output tsv)

Ottenere l'ID risorsa dell'identità gestita assegnata dall'utente

Per creare un cluster con un'identità gestita assegnata dall'utente, è necessario l'ID risorsa per la nuova identità gestita. Per ottenere l'ID risorsa dell'identità gestita assegnata dall'utente, chiamare az aks show ed eseguire una query sulla id proprietà :

RESOURCE_ID=$(az identity show \
    --name myIdentity \
    --resource-group myResourceGroup \
    --query id \
    --output tsv)

Assegnare un ruolo controllo degli accessi in base al ruolo di Azure all'identità gestita assegnata dall'utente

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

Nell'esempio seguente viene assegnato il ruolo Utente segreti dell'insieme di credenziali delle chiavi all'identità gestita assegnata dall'utente per concedergli le autorizzazioni per accedere ai segreti in un insieme di credenziali delle chiavi. L'assegnazione di ruolo ha come ambito la risorsa dell'insieme di credenziali delle chiavi:

az role assignment create \
    --assignee $CLIENT_ID \
    --role "Key Vault Secrets User" \
    --scope "<keyvault-resource-id>"

Nota

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

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

Per creare un cluster del servizio Azure Kubernetes con l'identità gestita assegnata dall'utente, chiamare il az aks create comando . Includere il --assign-identity parametro e passare l'ID risorsa per 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 \
    --assign-identity $RESOURCE_ID \
    --generate-ssh-keys

Nota

Le aree USDOD Central, USDOD East e USGov Iowa nel cloud di Azure US Government non supportano la creazione di un cluster con un'identità gestita assegnata dall'utente.

Aggiornare un cluster esistente per usare un'identità gestita assegnata dall'utente

Per aggiornare un cluster esistente per usare un'identità gestita assegnata dall'utente, chiamare il az aks update comando . Includere il --assign-identity parametro e passare l'ID risorsa per l'identità gestita assegnata dall'utente:

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity \
    --assign-identity $RESOURCE_ID

L'output per un aggiornamento corretto del cluster per l'uso di un'identità gestita assegnata dall'utente 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>"
      }
    }
  },

Nota

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

Determinare il tipo di identità gestita usata da un cluster

Per determinare il tipo di identità gestita usata dal cluster del servizio Azure Kubernetes esistente, chiamare il comando az aks show e la query per la proprietà type dell'identità.

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query identity.type \
    --output tsv

Se il cluster usa un'identità gestita, il valore della proprietà type sarà SystemAssigned o UserAssigned.

Se il cluster usa un'entità servizio, il valore della proprietà type sarà Null. Prendere in considerazione l'aggiornamento del cluster per usare un'identità gestita.

Usare un’Identità gestita Kubelet creata in modo preliminare

Un'identità kubelet creata in precedenza è un'identità gestita assegnata dall'utente esistente prima della creazione del cluster. Questa funzionalità abilita scenari come la connessione a Registro Azure Container durante la creazione del cluster.

Nota

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

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 sull'identità kubelet per l'identità gestita del piano di controllo.

Identità gestita kubelet

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

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"
}

Assegnare un ruolo controllo degli accessi in base al ruolo all'identità gestita kubelet

Assegnare il Managed Identity Operatorruolo nell'identità kubelet usando il comando az role assignment create. Specificare l'ID entità dell'identità kubelet per la variabile $KUBELET_CLIENT_ID.

az role assignment create \
    --assignee $KUBELET_CLIENT_ID \
    --role "Managed Identity Operator" \
    --scope "<kubelet-identity-resource-id>"

Creare un cluster per usare l'identità kubelet

È 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 comando az aks create.

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 \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id> \
    --generate-ssh-keys

Una creazione corretta del cluster del servizio Azure Kubelet con un'identità gestita kubelet dovrebbe comportare un output simile al 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 per usare l'identità kubelet

Per aggiornare un cluster esistente per usare l'identità gestita kubelet, ottenere prima di tutto l'identità gestita del piano di controllo corrente per il cluster del servizio Azure Kubernetes.

Avviso

L'aggiornamento dell'identità gestita kubelet consente di aggiornare i pool di nodi del cluster del servizio Azure Kubernetes, causando tempi di inattività per il cluster perché i nodi nei pool di nodi vengono filtrati/svuotati e ricreati l'immagine.

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

    az aks show \
    --resource-group <RGName> \
    --name <ClusterName> \
    --query "servicePrincipalProfile"

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

    # The cluster is using a managed identity.
{
  "clientId": "msi"
}

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

    az aks show --resource-group <RGName> \
    --name <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>"
},

  3. Aggiornare il cluster con le identità esistenti usando il comando az aks update. Specificare l'ID risorsa dell'identità gestita assegnata dall'utente per il piano di controllo per l'argomento assign-identity . Specificare l'ID risorsa dell'identità gestita kubelet per l'argomento assign-kubelet-identity .

    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"
    }
  },

Nota

Se il cluster usava --attach-acr per eseguire il pull dalle immagini da Registro Azure Container, 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 il pull da Registro Azure Container. In caso contrario, non sarà possibile eseguire il pull da Registro Azure Container dopo l'aggiornamento.

Ottenere le proprietà dell'identità kubelet

Per ottenere le proprietà dell'identità kubelet, chiamare az aks show ed eseguire query sulla identityProfile.kubeletidentity proprietà .

az aks show \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --query "identityProfile.kubeletidentity"

Limitazioni dell'identità kubelet create in anteprima

Si notino le limitazioni seguenti per l'identità kubelet creata in anteprima:

  • Un'identità kubelet creata in modo preliminare deve essere un'identità gestita assegnata dall'utente.
  • Le aree Cina orientale e Cina settentrionale in Microsoft Azure gestite da 21Vianet non sono supportate.

Riepilogo delle identità gestite usate dal servizio Azure Kubernetes

Il servizio Azure Kubernetes usa diverse identità gestite 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 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 AKS-agentpool Autenticazione con Registro Azure Container. 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 criteri di Azure (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 Instradamento dell'applicazione 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 (ACIConnector) Gestisce le risorse di rete necessarie per Istanze di Azure Container. 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

Importante

L'identità gestita da pod di Microsoft Entra open source (anteprima) nel servizio Azure Kubernetes è stata deprecata il 24/10/2022 e il progetto è stato archiviato a settembre 2023. Per altre informazioni, vedere Informativa sulle funzionalità deprecate. Il componente aggiuntivo gestito del servizio Azure Kubernetes inizia la deprecazione a settembre 2024.

È consigliabile esaminare ID dei carichi di lavoro di Microsoft Entra. Entra ID dei carichi di lavoro l'autenticazione sostituisce la funzionalità di identità gestita da pod deprecata (anteprima). Entra ID dei carichi di lavoro è il metodo consigliato per consentire a un'applicazione in esecuzione in un pod di eseguire l'autenticazione in altri servizi di Azure che lo supportano.

Limiti

  • Lo spostamento o la migrazione di un cluster abilitato per l'identità gestita a un tenant diverso 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 indica che qualsiasi richiesta inviata all'endpoint IMDS viene intercettata da NMI, anche se un particolare pod non usa aad-pod-identity.

    È possibile configurare la definizione di risorsa personalizzata (CRD) di AzurePodIdentityException per specificare che le richieste all'endpoint IMDS che hanno origine da un pod che corrispondono alle etichette definite nel CRD devono essere inoltrate tramite proxy senza alcuna elaborazione in NMI. Escludere i pod di sistema con l'etichetta kubernetes.azure.com/managedby: aks nello spazio dei nomi kube-system in aad-pod-identity configurando azurePodIdentityException CRD. Per altre informazioni, vedere Usare le identità gestite dai pod di Microsoft Entra in servizio Azure Kubernetes.

    Per configurare un'eccezione, installare il YAML mic-exception.

  • Il servizio Azure Kubernetes non supporta l'uso di un'identità gestita assegnata dal sistema quando si usa una zona DNS privata personalizzata.

Passaggi successivi