Verwenden einer verwalteten Identität in Azure Kubernetes Service (AKS)

  • Artikel

AKS-Cluster (Azure Kubernetes Service) erfordern eine Identität, um auf Azure-Ressourcen wie Lastenausgleichsmodule und verwaltete Datenträger zuzugreifen. Dabei kann es sich um eine verwaltete Identität oder einen Dienstprinzipal handeln.

Dieser Artikel enthält Details zum Aktivieren der folgenden Typen von verwalteten Identitäten für einen neuen oder vorhandenen AKS-Cluster:

  • Systemseitig zugewiesene verwaltete Identität
  • Einbringen einer eigenen benutzerseitig zugewiesenen verwalteten Identität
  • Vorab erstellte verwaltete Kubelet-Identität

Überblick

Wenn Sie einen AKS-Cluster bereitstellen, wird automatisch eine systemseitig zugewiesene verwaltete Identität erstellt und von der Azure-Plattform verwaltet, sodass Sie keine Geheimnisse bereitstellen oder rotieren müssen. Weitere Informationen finden Sie unter verwaltete Identitäten für Azure-Ressourcen.

Ein Dienstprinzipal wird nicht automatisch von AKS erstellt, sodass Sie einen erstellen müssen. Cluster, die ein Dienstprinzipal verwenden, laufen irgendwann aus, und das Dienstprinzipal muss erneuert werden, damit die Cluster-Authentifizierung mit der Identität nicht beeinträchtigt wird. Das Verwalten von Dienstprinzipalen erhöht die Komplexität, weshalb es einfacher ist, verwaltete Identitäten zu verwenden. Dieselben Berechtigungsanforderungen gelten sowohl für Dienstprinzipale als auch für verwaltete Identitäten. Verwaltete Identitäten verwenden die zertifikatbasierte Authentifizierung. Die Anmeldeinformationen für jede verwaltete Identität haben eine Gültigkeitsdauer von 90 Tagen und werden nach 45 Tagen rotiert.

AKS verwendet sowohl systemseitig zugewiesene als auch benutzerseitig zugewiesene verwaltete Identitätstypen, und diese Identitäten sind unveränderlich. Diese Identitätstypen sollten nicht mit einer Microsoft Entra Workload-Identitätverwechselt werden, die für die Verwendung durch eine Anwendung vorgesehen ist, die auf einem Pod ausgeführt wird.

Wichtig

Die Podseitig verwaltete Open-Source-Identität von Microsoft Entra (Vorschau) in Azure Kubernetes Service wurde zum 24.10.2022 eingestellt, und das Projekt wurde im September 2023 archiviert. Weitere Informationen finden Sie im Hinweis zur Einstellung. Das Add-On für verwaltete Identitäten in AKS wird im September 2024 eingestellt.

Es wird empfohlen, zunächst die Übersicht über die Microsoft Entra-Workload-ID zu lesen. Die Entra Workload ID-Authentifizierung ersetzt die von Microsoft Entra verwaltete Identität (Vorschau) und ist die empfohlene Methode, um eine Anwendung zu ermöglichen, die auf einem Pod ausgeführt wird, um sich bei anderen Azure-Diensten zu authentifizieren, die sie unterstützen.

Voraussetzungen

Begrenzungen

  • Das Verschieben oder Migrieren von Clustern mit aktivierter verwalteter Identität wird für Mandanten nicht unterstützt.
  • Wenn für den Cluster die verwaltete Microsoft Entra-Podidentität (aad-pod-identity) aktiviert wurde, werden die iptables der Knoten von NMI-Pods (Node Managed Identity) so geändert, dass Aufrufe des Azure Instance Metadata-Endpunkts (IMDS) abgefangen werden. Diese Konfiguration bedeutet, dass jede Anforderung, die an den Metadatenendpunkt gerichtet ist, von NMI abgefangen wird, auch wenn aad-pod-identity vom Pod nicht verwendet wird. Die AzurePodIdentityException-CRD kann so konfiguriert werden, dass aad-pod-identity darüber informiert wird, dass an den Metadatenendpunkt gerichtete Anforderungen, die von einem Pod stammen, der in der CRD definierte Bezeichnungen abgleicht, ohne Verarbeitung in NMI über einen Proxy zu senden sind. Die Systempods mit der Bezeichnung kubernetes.azure.com/managedby: aks im Namespace kubernetes.azure.com/managedby: aks müssen in aad-pod-identity durch Konfiguration der AzurePodIdentityException-CRD ausgeschlossen werden.
  • AKS unterstützt die Verwendung einer systemseitig zugewiesenen verwalteten Identität bei Verwendung einer benutzerdefinierten privaten DNS-Zone nicht.

Zusammenfassung der verwalteten Identitäten

AKS verwendet mehrere verwaltete Identitäten für integrierte Dienste und Add-Ons.

Identity Name Anwendungsfall Standardberechtigungen Verwendung eigener Identitäten
Steuerungsebene Name des AKS-Clusters Wird von Komponenten der AKS-Steuerungsebene verwendet, um Clusterressourcen wie Lastenausgleichsmodule für eingehenden Datenverkehr und von AKS verwaltete öffentliche IP-Adressen, die Autoskalierung im Cluster sowie CSI-Treiber für Datenträger, Dateien und Blobs in Azure zu verwalten. Rolle „Mitwirkender“ für Knotenressourcengruppe Unterstützt
Kubelet Name des AKS-Clusters: agentpool Authentifizierung bei Azure Container Registry (ACR). N/V (für Kubernetes v1.15 und höher) Unterstützt
Add-On AzureNPM Keine Identität erforderlich. – Nein
Add-On Azure CNI-Netzwerküberwachung Keine Identität erforderlich. – Nein
Add-On azure-policy (Gatekeeper) Keine Identität erforderlich. – Nein
Add-On azure-policy Keine Identität erforderlich. – Nein
Add-On Calico Keine Identität erforderlich. – Nein
Add-On Dashboard Keine Identität erforderlich. – Nein
Add-On Anwendungsrouting Verwaltet Azure DNS- und Azure Key Vault-Zertifikate Rolle „Benutzer von Key VaultGeheimnissen“ für Key Vault, Rolle „DNZ-Zonenmitwirkender“ für DNS-Zonen, Rolle „Private DNS-Zonenmitwirkender“ für private DNS-Zonen Nein
Add-On HTTPApplicationRouting Verwaltung erforderlicher Netzwerkressourcen. Rolle „Leser“ für Knotenressourcengruppe, Rolle „Mitwirkender“ für DNS-Zone Nein
Add-On Anwendungsgateway für eingehenden Datenverkehr Verwaltung erforderlicher Netzwerkressourcen. Rolle „Mitwirkender“ für Knotenressourcengruppe Nein
Add-On omsagent Senden von AKS-Metriken an Azure Monitor. Rolle „Herausgeber von Überwachungsmetriken“ Nein
Add-On Virtual-Node (ACI-Connector) Verwaltung erforderlicher Netzwerkressourcen für Azure Container Instances (ACI). Rolle „Mitwirkender“ für Knotenressourcengruppe Nein
Add-On Kostenanalyse Wird verwendet, um Kostenzuteilungsdaten zu sammeln
Workloadidentität Microsoft Entra Workload ID Ermöglicht Anwendungen den sicheren Zugriff auf Cloud-Ressourcen mit Microsoft Entra Workload ID. N/V No

Aktivieren von verwalteten Identitäten in einem neuen AKS-Cluster

Hinweis

AKS erstellt eine benutzerseitig zugewiesene Kubelet-Identität in der Knotenressourcengruppe, wenn Sie keine eigene verwaltete Kubelet-Identität angeben.

Hinweis

Wenn Ihr Cluster bereits eine verwaltete Identität verwendet und die Identität geändert wurde, da Sie z. B. den Clusteridentitätstyp von systemseitig in benutzerseitig zugewiesen geändert haben, tritt bei der Umstellung auf die neue Identität eine Verzögerung bei Komponenten auf Steuerungsebene auf. Komponenten auf Steuerungsebene verwenden die alte Identität so lange weiter, bis ihr Token abläuft. Nachdem das Token aktualisiert wurde, wechseln sie zur neuen Identität. Dieser Prozess kann mehrere Stunden dauern.

  1. Erstellen Sie mithilfe des Befehls az group create eine Azure-Ressourcengruppe.

    az group create --name myResourceGroup --location westus2

  2. Erstellen Sie mit dem Befehl az aks create einen AKS-Cluster.

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

  3. Rufen Sie die Anmeldeinformationen für den Zugriff auf den Cluster mit dem Befehl az aks get-credentials ab.

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

Aktivieren von verwalteten Identitäten in einem vorhandenen AKS-Cluster

Um Ihren bestehenden AKS-Cluster, der ein Dienstprinzipal verwendet, zu aktualisieren, damit er eine vom System zugewiesene verwaltete Identität verwendet, führen Sie den Befehl az aks update aus.

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

Nach dem Aktualisieren Ihres Clusters verwenden die Steuerungsebene und Pods die verwaltete Identität. Kubelet verwendet weiterhin einen Dienstprinzipal, bis Sie Ihren Agentpool aktualisieren. Sie können den Befehl az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only auf Ihren Knoten verwenden, um auf eine verwaltete Identität zu aktualisieren. Das Upgrade der Knotenpools verursacht Ausfallzeiten für Ihren AKS-Cluster, da die Knoten in den Knotenpools gesperrt/ausgeglichen werden und ein erneutes Image erstellt wird.

Hinweis

Beachten Sie beim Aktualisieren Ihres Clusters die folgenden Informationen:

  • Eine Aktualisierung funktioniert nur, wenn ein VHD-Update verwendet werden kann. Wenn Sie die neueste VHD ausführen, müssen Sie warten, bis die nächste VHD verfügbar wird, um die Aktualisierung vorzunehmen.

  • Die Azure CLI stellt sicher, dass die Berechtigung Ihres Add-Ons nach der Migration richtig festgelegt ist. Wenn Sie nicht die Azure CLI zum Durchführen des Migrationsvorgangs verwenden, müssen Sie die Berechtigung der Add-On-Identität selbst festlegen. Ein Beispiel für die Verwendung einer ARM-Vorlage (Azure Resource Manager) finden Sie unter Zuweisen von Azure-Rollen mithilfe von ARM-Vorlagen.

  • Wenn Ihr Cluster --attach-acr zum Pullen aus Images aus Azure Container Registry verwendet hat, müssen Sie nach dem Aktualisieren Ihres Clusters den Befehl az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR resource ID> ausführen, damit die neu erstellte Kubelet-Instanz, die für die verwaltete Identität verwendet wird, die Berechtigung zum Pullen aus ACR erhält. Andernfalls können Sie nach der Aktualisierung keinen Pull aus ACR ausführen.

Hinzufügen der Rollenzuweisung für eine verwaltete Identität

Wenn Sie ein eigenes VNet erstellen und verwenden, Azure-Festplatten, eine statische IP-Adresse, eine Routentabelle oder eine vom benutzerseitig zugewiesene kubelet-Identität zuweisen, wenn sich die Ressourcen außerhalb der Worker Node-Ressourcengruppe befinden, fügt die Azure CLI die Rollenzuweisung automatisch hinzu. Wenn Sie eine ARM-Vorlage oder eine andere Methode verwenden, müssen Sie die Prinzipal-ID der vom Cluster verwalteten Identität verwenden, um eine Rollenzuweisung durchzuführen.

Wenn Sie nicht die Azure CLI verwenden, sondern Ihr eigenes VNet, Azure-Festplatten, eine statische IP-Adresse, eine Routentabelle oder eine benutzerseitig zugewiesene kubelet-Identität außerhalb der Worker Node-Ressourcengruppe nutzen, empfehlen wir die Verwendung einer benutzerseitig zugewiesenen verwalteten Identität für die Steuerungsebene. Damit die Steuerebene eine systemseitig zugewiesene verwaltete Identität verwenden kann, können wir die Identitäts-ID vor der Erstellung des Clusters nicht abrufen, wodurch sich das Wirksamwerden der Rollenzuweisung verzögert.

Abrufen der Prinzipal-ID der verwalteten Identität

  • Rufen Sie die Prinzipal-ID der vorhandenen Identität mit dem Befehl az identity show ab.

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

    Ihre Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

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

Rollenzuweisung hinzufügen

Für ein VNet, einen angefügten Azure-Datenträger, eine statische IP-Adresse oder eine Routingtabelle, die sich außerhalb der standardmäßigen Workerknoten-Ressourcengruppe befinden, müssen Sie die Contributor-Rolle für die benutzerdefinierte Ressourcengruppe zuweisen.

  • Weisen Sie die Contributor-Rolle für die benutzerdefinierte Ressourcengruppe mit dem Befehl az role assignment create zu.

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

Für eine benutzerseitig zugewiesene kubelet-Identität außerhalb der standardmäßigen Worker-Node-Ressourcengruppe müssen Sie der kubelet-Identität die Rolle Operator für verwaltete Identitäten auf Steuerungsebene zuweisen.

  • Weisen Sie die Managed Identity Operator-Rolle für die Kubelet-Identität mit dem Befehl az role assignment create zu.

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

Hinweis

Es kann bis zu 60 Minuten dauern, bis die Berechtigungen, die der verwalteten Identität Ihres Clusters erteilt wurden, eingetragen sind.

Verwendung eigener verwalteter Identitäten

Erstellen eines Clusters anhand der benutzerseitig zugewiesenen verwalteten Identität

Eine benutzerdefinierte, verwaltete Identität für die Steuerungsebene ermöglicht den Zugriff auf die vorhandene Identität vor der Erstellung des Clusters. Dieses Feature ermöglicht beispielsweise die Verwendung eines benutzerdefinierten VNet oder einer UDR vom Typ „outboundType“ mit einer vorab erstellten verwalteten Identität.

Hinweis

Die Regionen „US DoD, Mitte“, „US DoD, Osten“ und „USGov Iowa“ in der Azure US Government-Cloud werden nicht unterstützt.

AKS erstellt eine benutzerseitig zugewiesene Kubelet-Identität in der Knotenressourcengruppe, wenn Sie keine eigene verwaltete Kubelet-Identität angeben.

  • Sollten Sie über keine verwaltete Identität verfügen, erstellen Sie eine mit dem Befehl az identity create.

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

    Ihre Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

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

Hinweis

Es kann bis zu 60 Minuten dauern, bis die Berechtigungen, die der verwalteten Identität Ihres Clusters erteilt wurden, eingetragen sind.

Verwaltete Identität auf einem bestehenden Cluster aktualisieren

Hinweis

Die Migration einer verwalteten Identität für die Steuerungsebene von systemseitig zu benutzerseitig verursacht keine Ausfallzeiten für Steuerungsebene und Agentpools. In der Zwischenzeit verwenden die Komponenten der Steuerungsebene die alte, systemseitig zugewiesene Identität für einige Stunden bis zur nächsten Token-Aktualisierung weiter.

  • Sollten Sie über keine verwaltete Identität verfügen, erstellen Sie eine mit dem Befehl az identity create.

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

    Ihre Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

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

  • Nachdem Sie die benutzerdefinierte benutzerseitig zugewiesene verwaltete Identität für die Steuerungsebene erstellt haben, fügen Sie die Rollenzuweisung für die verwaltete Identität mithilfe des Befehls az role assignment create hinzu.

  • Aktualisieren Sie mithilfe des Befehls az aks update Ihren Cluster mit den vorhandenen Identitäten. Achten Sie darauf, dass Sie die Ressourcen-ID der verwalteten Identität für die Steuerungsebene angeben, indem Sie das Argument assign-identity einschließen.

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

    Die Ausgabe bei einer erfolgreichen Clusteraktualisierung unter Verwendung Ihrer eigenen verwalteten Kubelet-Identität sollte der folgenden Beispielausgabe ähneln:

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

Verwenden einer vorab erstellten verwalteten Kubelet-Identität

Eine Kubelet-Identität ermöglicht den Zugriff auf die vorhandene Identität vor der Clustererstellung. Diese Funktion ermöglicht Szenarien wie die Verbindung zu ACR mit einer zuvor erstellten verwalteten Identität.

Einschränkungen für die vorab erstellte Kubelet-Identität

  • Es funktioniert ausschließlich mit einem benutzerseitig zugewiesenen verwalteten Cluster.
  • Die Regionen „China, Osten“ und „China, Norden“ werden in Microsoft Azure operated by 21Vianet nicht unterstützt.

Erstellen benutzerseitig zugewiesener verwalteter Identitäten

Verwaltete Steuerungsebenenidentität

  • Wenn Sie keine verwaltete Identität für die Kontrollebene haben, erstellen Sie mit az identity create eine.

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

    Ihre Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

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

Verwaltete Kubelet-Identität

  • Sollten Sie über keine verwaltete Kubelet-Identität verfügen, erstellen Sie eine mit dem Befehl az identity create.

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

    Ihre Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

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

Erstellen eines Clusters anhand der benutzerseitig zugewiesenen Kubelet-Identität

Sie können jetzt Ihren AKS-Cluster mit den vorhandenen Identitäten erstellen. Stellen Sie sicher, dass Sie die Ressourcen-ID der verwalteten Identität für die Steuerungsebene mit dem Argument assign-identity und die verwaltete kubelet-Identität mit dem Argument assign-kubelet-identity angeben.

  • Erstellen Sie mithilfe des Befehls az aks create einen AKS-Cluster mit den vorhandenen Identitäten.

    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>

    Eine erfolgreiche AKS-Clustererstellung unter Verwendung Ihrer eigenen verwalteten Kubelet-Identität sollte der folgenden Beispielausgabe ähneln:

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

Aktualisieren eines vorhandenen Clusters mithilfe der Kubelet-Identität

Warnung

Durch die Aktualisierung der verwalteten Kubelet-Identität erfolgt ein Upgrade der Knotenpools, was zu Ausfallzeiten für Ihren AKS-Cluster führt, da die Knoten in den Knotenpools gesperrt/ausgeglichen werden und ein erneutes Image erstellt wird.

Hinweis

Wenn Ihr Cluster --attach-acr zum Pullen aus Images aus Azure Container Registry verwendet hat, müssen Sie nach dem Aktualisieren Ihres Clusters den Befehl az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR Resource ID> ausführen, damit die neu erstellte Kubelet-Instanz, die für die verwaltete Identität verwendet wird, die Berechtigung zum Pullen aus ACR erhält. Andernfalls können Sie nach dem Upgrade keinen Pull aus ACR ausführen.

Abrufen der aktuellen auf der Steuerungsebene verwalteten Identität für Ihren AKS-Cluster

  1. Bestätigen Sie mit dem Befehl az aks show, dass Ihr AKS-Cluster die benutzerseitig zugewiesene verwaltete Identität verwendet.

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

    Wenn Ihr Cluster eine verwaltete Identität verwendet, zeigt die Ausgabe clientId mit dem Wert msi an. Ein Cluster mit einem Dienstprinzipal zeigt eine Objekt-ID an. Beispiel:

    {
  "clientId": "msi"
}

  2. Nachdem Sie sich vergewissert haben, dass Ihr Cluster eine verwaltete Identität verwendet, suchen Sie die Ressourcen-ID der verwalteten Identität mit dem Befehl az aks show.

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

    Für eine benutzerseitig zugewiesene verwaltete Identität sollte Ihre Ausgabe ungefähr so aussehen wie die folgende Beispielausgabe:

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

Aktualisieren Ihres Clusters mit Kubelet-Identität

  1. Sollten Sie über keine verwaltete Kubelet-Identität verfügen, erstellen Sie eine mit dem Befehl az identity create.

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

    Ihre Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

    {
  "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. Aktualisieren Sie mithilfe des Befehls az aks update Ihren Cluster mit den vorhandenen Identitäten. Stellen Sie sicher, dass Sie die Ressourcenkennung der verwalteten Identität für die Kontrollebene mit dem Argument assign-identity und die verwaltete kubelet-Identität mit dem Argument assign-kubelet-identity angeben.

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

    Die Ausgabe bei einer erfolgreichen Clusteraktualisierung unter Verwendung Ihrer eigenen verwalteten Kubelet-Identität sollte der folgenden Beispielausgabe ähneln:

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

Nächste Schritte

  • Verwenden Sie Azure Resource Manager-Vorlagen zum Erstellen eines Clusters mit aktivierter verwalteter Identität.
  • Erfahren Sie, wie Sie [kubelogin][kubelogin-authentication] für alle unterstützten Microsoft Entra-Authentifizierungsmethoden in AKS verwenden.