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

  • Articolo

i cluster servizio Azure Kubernetes (AKS) richiedono 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. Quando si crea un cluster del servizio Azure Kubernetes, viene creata automaticamente un'identità gestita assegnata dal sistema. Questa identità viene gestita dalla piattaforma Azure e non richiede il provisioning o la rotazione di segreti. Per altre informazioni sulle identità gestite in Azure AD, 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 scadono e l'entità servizio deve essere rinnovata per evitare l'impatto 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 per le entità servizio che per le 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 i tipi di identità gestiti assegnati dal sistema e assegnati dall'utente e queste identità sono non modificabili.

Nota

Se si sta valutando l'implementazione dell'identità gestita dai pod di Azure AD nel cluster del servizio Azure Kubernetes, è consigliabile esaminare prima di tutto la panoramica dell'identità del carico di lavoro di Azure AD. Questo metodo di autenticazione sostituisce l'identità gestita dal pod di Azure AD (anteprima) ed è il metodo consigliato.

Prima di iniziare

Limitazioni

  • I tenant che spostano o eseguono la migrazione di un cluster abilitato per l'identità gestita non sono supportati.
  • Se il cluster ha l'identità gestita dai pod di Azure AD () abilitata, Node-Managed pod Identity (aad-pod-identityNMI) modificano le tabelle iptable dei nodi per intercettare le chiamate all'endpoint IMDS (Azure Instance Metadata). Questa configurazione indica 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 qualsiasi richiesta all'endpoint metadati proveniente da un pod che corrisponde alle etichette definite in CRD 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 configurando il CRD AzurePodIdentityException.
  • Il servizio Azure Kubernetes non supporta l'uso di un'identità gestita assegnata dal sistema se 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 Portare 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 servizio di scalabilità automatica del cluster, il disco di Azure, file, i driver BLOB CSI. Ruolo collaboratore per il gruppo di risorse Node Supportato
Kubelet Cluster Name-agentpool del servizio Azure Kubernetes Autenticazione con Registro Azure Container (ACR). N/A (per kubernetes v1.15+) Supportato
Componente aggiuntivo AzureNPM Nessuna identità necessaria. N/D No
Componente aggiuntivo Monitoraggio della 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 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 metriche del servizio Azure Kubernetes a Monitoraggio di Azure. Ruolo server di pubblicazione delle metriche di monitoraggio No
Componente aggiuntivo Virtual-Node (ACIConnector) Gestisce le risorse di rete necessarie per Istanze di Azure Container (ACI). Ruolo collaboratore per il gruppo di risorse del nodo No
Progetto OSS aad-pod-identity Consente alle applicazioni di accedere in modo sicuro alle risorse cloud con Microsoft Azure Active Directory (Azure AD). N/D Passaggi per concedere l'autorizzazione alla configurazione dell'assegnazione del ruolo pod di Azure AD.

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 l'identità gestita kubelet personalizzata][Usare un'identità gestita kubelet predefinita].

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

    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 aver aggiornato il cluster, il piano di controllo e i pod usano l'identità gestita. kubelet continua a usare un'entità servizio finché non si aggiorna agentpool. È possibile usare il comando nei nodi per aggiornare a un'identità az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only 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 delimitati/scaricati e ricreati.

Nota

Tenere presenti le informazioni seguenti durante l'aggiornamento del cluster:

  • 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 di addon 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 l'autorizzazione dell'identità addon autonomamente. Per un esempio che usa un modello di Azure Resource Manager (ARM), vedere Assegnare ruoli di Azure con 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 ACR dopo l'aggiornamento.

Aggiungere l'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 del 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 al di fuori 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 un cluster, che ritarda l'assegnazione del ruolo dall'effetto.

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 all'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

Può richiedere fino a 60 minuti per le autorizzazioni concesse all'identità gestita del cluster per popolare.

Portare un'identità gestita personalizzata

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à consente scenari come l'uso di una rete virtuale personalizzata o un tipo in uscita di UDR con un'identità gestita pre-creata.

Nota

Le aree 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 l'identità gestita kubelet personalizzata][Usare un'identità gestita kubelet predefinita].

  • Se non si dispone di 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

Può richiedere fino a 60 minuti per le autorizzazioni concesse all'identità gestita del cluster per popolare.

  • Prima di creare il cluster, [aggiungere l'assegnazione di ruolo per l'identità gestita][add-role-assignment-for-managed-identity] usando il az role assignment create comando .

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

    az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --network-plugin azure \
    --vnet-subnet-id <subnet-id> \
    --docker-bridge-address 172.17.0.1/16 \
    --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 assegnato all'utente, non causa tempi di inattività per i pool del piano di controllo e dell'agente. Nel frattempo, i componenti del piano di controllo continueranno a usare l'identità assegnata dal sistema precedente per diverse ore fino all'aggiornamento del token successivo.

  • Se non si dispone di 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à, aggiungere l'assegnazione di ruolo per l'identità gestita del piano di controllo 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 del cluster riuscito 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 predefinita

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

Limitazioni dell'identità kubelet predefinite

  • 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 dispone di 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> \
    --docker-bridge-address 172.17.0.1/16 \
    --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>

    La creazione di un cluster del servizio Azure Kubelet con esito positivo usando la propria identità gestita kubelet dovrebbe essere simile all'output dell'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, poiché i nodi nei pool di nodi verranno delimitati/scaricati e ricreati.

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 mostra 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 dispone di 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à gestita kubelet per assign-kubelet-identity l'argomentoassign-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 del cluster riuscito 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 modelli di Azure Resource Manager per creare un cluster abilitato per l'identità gestita.