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

  • Artikel

AKS-Cluster (Azure Kubernetes Service) erfordern eine Microsoft Entra-Identität, um auf Azure-Ressourcen wie Lastenausgleichsmodule und verwaltete Datenträger zuzugreifen. Verwaltete Identitäten für Azure-Ressourcen sind die empfohlene Methode, um den Zugriff von einem AKS-Cluster auf andere Azure-Dienste zu autorisieren.

Sie können eine verwaltete Identität verwenden, um den Zugriff von einem AKS-Cluster auf einen beliebigen Dienst zu autorisieren, der die Microsoft Entra-Autorisierung unterstützt, ohne Anmeldeinformationen verwalten oder in Ihren Code einschließen zu müssen. Sie weisen der verwalteten Identität eine rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) zu, um ihr Berechtigungen für eine bestimmte Ressource in Azure zu erteilen. Sie können z. B. Berechtigungen für eine verwaltete Identität erteilen, um auf Geheimnisse in einem Azure-Schlüsseltresor zuzugreifen, der vom Cluster verwendet werden soll. Weitere Informationen zu Azure RBAC finden Sie unter Was ist die rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC)?.

In diesem Artikel wird gezeigt, wie Sie die folgenden Typen von verwalteter Identität für einen neuen oder vorhandenen AKS-Cluster aktivieren:

  • Systemseitig zugewiesene verwaltete Identität. Eine systemseitig zugewiesene verwaltete Identität ist einer einzigen Azure-Ressource zugeordnet, z. B. einem AKS-Cluster. Sie ist nur für den Lebenszyklus des Clusters vorhanden.
  • Dem Benutzer zugewiesene verwaltete Identität. Eine benutzerseitig zugewiesene verwaltete Identität ist eine eigenständige Azure-Ressource, die ein AKS-Cluster verwenden kann, um den Zugriff auf andere Azure-Dienste zu autorisieren. Sie wird separat vom AKS-Cluster beibehalten und kann von mehreren Azure-Ressourcen verwendet werden.
  • Vorab erstellte verwaltete Kubelet-Identität. Eine vorab erstellte verwaltete Kubelet-Identität ist eine optionale benutzerseitig zugewiesene Identität, die Kubelet für den Zugriff auf andere Ressourcen in Azure verwenden kann. Wenn Sie keine benutzerseitig zugewiesene verwaltete Identität für Kubelet angeben, erstellt AKS eine systemseitig zugewiesene Kubelet-Identität in der Knotenressourcengruppe.

Weitere Informationen zu verwalteten Identitäten finden Sie unter Verwaltete Identitäten für Azure-Ressourcen.

Übersicht

Ein AKS-Cluster verwendet eine verwaltete Identität, um Token von Microsoft Entra anzufordern. Diese Token werden verwendet, um den Zugriff auf andere Ressourcen zu autorisieren, die in Azure ausgeführt werden. Sie können einer verwalteten Identität eine Azure RBAC-Rolle zuweisen, um Ihrem Cluster Berechtigungen für den Zugriff auf bestimmte Ressourcen zu gewähren. Wenn Ihr Cluster beispielsweise auf Geheimnisse in einem Azure-Schlüsseltresor zugreifen muss, können Sie der verwalteten Identität des Clusters eine Azure RBAC-Rolle zuweisen, die diese Berechtigungen gewährt.

Eine verwaltete Identität kann entweder systemseitig oder benutzerseitig zugewiesen werden. Diese beiden Typen von verwalteten Identitäten sind ähnlich, da Sie beide Typen verwenden können, um den Zugriff auf Azure-Ressourcen von Ihrem AKS-Cluster zu autorisieren. Der Hauptunterschied zwischen ihnen besteht darin, dass eine systemseitig zugewiesene verwaltete Identität einer einzigen Azure-Ressource wie einem AKS-Cluster zugeordnet ist, während eine benutzerseitig zugewiesene verwaltete Identität selbst eine eigenständige Azure-Ressource ist. Weitere Informationen zu den Unterschieden zwischen den Typen von verwalteten Identitäten finden Sie unter Verwaltete Identitätstypen in Verwaltete Identitäten für Azure-Ressourcen.

Beide Typen von verwalteten Identitäten werden von der Azure-Plattform verwaltet, sodass Sie den Zugriff von Ihren Anwendungen autorisieren können, ohne Geheimnisse bereitstellen oder rotieren zu müssen. Azure verwaltet die Anmeldeinformationen der Identität für Sie.

Wenn Sie einen AKS-Cluster bereitstellen, wird standardmäßig eine systemseitig zugewiesene verwaltete Identität erstellt. Sie können den Cluster auch mit einer benutzerseitig zugewiesenen verwalteten Identität erstellen.

Es ist auch möglich, einen Cluster mit einem Anwendungsdienstprinzipal zu erstellen, anstatt eine verwaltete Identität zu verwenden. Verwaltete Identitäten werden aufgrund von Sicherheit und Benutzerfreundlichkeit gegenüber Dienstprinzipalen empfohlen. Weitere Informationen zum Erstellen eines Clusters mit einem Dienstprinzipal finden Sie unter Verwenden eines Dienstprinzipals mit Azure Kubernetes Service (AKS).

Sie können einen vorhandenen Cluster aktualisieren, um eine verwaltete Identität von einem Anwendungsdienstprinzipal zu verwenden. Sie können auch einen vorhandenen Cluster auf einen anderen Typ von verwalteter Identität aktualisieren. Wenn Ihr Cluster bereits eine verwaltete Identität verwendet und die Identität geändert wurde, z. B. wenn Sie den Clusteridentitätstyp von systemseitig in benutzerseitig zugewiesen geändert haben, dann tritt bei der Umstellung der Komponenten auf Steuerungsebene auf die neue Identität eine Verzögerung auf. Die Komponenten auf Steuerungsebene verwenden weiterhin die alte Identität, bis ihr Token abläuft. Nachdem das Token aktualisiert wurde, wechseln sie zur neuen Identität. Dieser Prozess kann mehrere Stunden dauern.

Die systemseitig und benutzerseitig zugewiesenen Identitätstypen unterscheiden sich von einer Microsoft Entra-Workloadidentität, die für die Verwendung durch eine Anwendung vorgesehen ist, die auf einem Pod ausgeführt wird.

Voraussetzungen

Bevor Sie die Beispiele in diesem Artikel ausführen, legen Sie Ihr Abonnement als aktuelles aktives Abonnement fest, indem Sie den Befehl az account set aufrufen und Ihre Abonnement-ID übergeben.

az account set --subscription <subscription-id>

Erstellen Sie auch eine Azure-Ressourcengruppe, wenn Sie noch keine haben, indem Sie den Befehl az group create aufrufen.

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

Aktivieren einer systemseitig zugewiesenen verwalteten Identität

Eine systemseitig zugewiesene verwaltete Identität ist eine Identität, die einem AKS-Cluster oder einer anderen Azure-Ressource zugeordnet ist. Die systemseitig zugewiesene verwaltete Identität ist an den Lebenszyklus des Clusters gebunden. Wenn der Cluster gelöscht wird, wird auch die systemseitig zugewiesene verwaltete Identität gelöscht.

Der AKS-Cluster kann die systemseitig zugewiesene verwaltete Identität verwenden, um den Zugriff auf andere Ressourcen zu autorisieren, die in Azure ausgeführt werden. Sie können der systemseitig zugewiesenen verwalteten Identität eine Azure RBAC-Rolle zuweisen, um dem Cluster Berechtigungen für den Zugriff auf bestimmte Ressourcen zu gewähren. Wenn Ihr Cluster beispielsweise auf Geheimnisse in einem Azure-Schlüsseltresor zugreifen muss, können Sie der systemseitig zugewiesenen verwalteten Identität eine Azure RBAC-Rolle zuweisen, die diese Berechtigungen gewährt.

Aktivieren einer systemseitig zugewiesenen verwalteten Identität in einem neuen AKS-Cluster

Rufen Sie den Befehl az aks create auf, um eine systemseitig zugewiesene verwaltete Identität in einem neuen Cluster zu aktivieren. Standardmäßig ist eine systemseitig zugewiesene verwaltete Identität im neuen Cluster aktiviert.

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

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

Informationen zum Verifizieren, ob eine systemseitig zugewiesene verwaltete Identität nach der Erstellung für den Cluster aktiviert ist, finden Sie unter Ermitteln, welchen Typ von verwalteter Identität ein Cluster verwendet.

Aktualisieren eines vorhandenen AKS-Clusters zur Verwendung einer systemseitig zugewiesenen verwalteten Identität

Um einen bestehenden AKS-Cluster, der ein Dienstprinzipal verwendet, zu aktualisieren, damit er stattdessen eine systemseitig zugewiesene verwaltete Identität verwendet, führen Sie den Befehl az aks update mit dem Parameter --enable-managed-identity aus.

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

Nachdem Sie den Cluster so aktualisiert haben, dass anstelle eines Dienstprinzipals eine systemseitig zugewiesene verwaltete Identität verwendet wird, verwenden die Steuerungsebene und Pods die systemseitig zugewiesene verwaltete Identität für die Autorisierung beim Zugriff auf andere Dienste in Azure. Kubelet verwendet weiterhin einen Dienstprinzipal, bis Sie für Ihren Agentpool auch ein Upgrade durchführen. 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 und ausgeglichen werden und ein neues Image der Knoten 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 (ACR) 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 einer Rollenzuweisung für eine systemseitig zugewiesene verwaltete Identität

Sie können der systemseitig zugewiesenen verwalteten Identität eine Azure RBAC-Rolle zuweisen, um dem Cluster Berechtigungen für eine andere Azure-Ressource zu gewähren. Azure RBAC unterstützt sowohl integrierte als auch benutzerdefinierte Rollendefinitionen, die Berechtigungsebenen angeben. Weitere Informationen zum Zuweisen von Azure RBAC-Rollen finden Sie unter Schritte zum Zuweisen einer Azure-Rolle.

Wenn Sie einer verwalteten Identität eine Azure RBAC-Rolle zuweisen, müssen Sie den Bereich für die Rolle definieren. Im Allgemeinen empfiehlt es sich, den Bereich einer Rolle auf die Mindestberechtigungen zu beschränken, die von der verwalteten Identität benötigt werden. Weitere Informationen zur Bereichsdefinition für Azure RBAC-Rollen finden Sie unter Grundlegendes zum Bereich von Azure RBAC.

Wenn Sie ein eigenes VNet, einen angefügten Azure-Datenträger, eine statische IP-Adresse, eine Routingtabelle oder eine benutzerseitig zugewiesene Kubelet-Identität erstellen und verwenden, bei denen die Ressourcen außerhalb der Workerknoten-Ressourcengruppe liegen, fügt die Azure CLI die Rollenzuweisung automatisch hinzu. Wenn Sie eine ARM-Vorlage oder eine andere Methode nutzen, verwenden Sie die Prinzipal-ID der verwalteten Identität, um eine Rollenzuweisung durchzuführen.

Wenn Sie nicht die Azure CLI verwenden, sondern ein eigenes VNet, einen angefügten Azure-Datenträger, eine statische IP-Adresse, eine Routingtabelle oder eine benutzerseitig zugewiesene Kubelet-Identität außerhalb der Workerknoten-Ressourcengruppe nutzen, empfehlen wir die Verwendung einer benutzerseitig zugewiesenen verwalteten Identität für die Steuerungsebene. Wenn die Steuerungsebene eine systemseitig zugewiesene verwaltete Identität verwendet, wird die Identität gleichzeitig mit dem Cluster erstellt, sodass die Rollenzuweisung erst ausgeführt werden kann, wenn der Cluster erstellt wurde.

Abrufen der Prinzipal-ID der systemseitig zugewiesenen verwalteten Identität

Um der systemseitig zugewiesenen verwalteten Identität eines Clusters eine Azure RBAC-Rolle zuzuweisen, benötigen Sie zunächst die Prinzipal-ID für die verwaltete Identität. Rufen Sie die Prinzipal-ID für die systemseitig zugewiesene verwaltete Identität des Clusters ab, indem Sie den Befehl az aks show aufrufen.

# 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)

Zuweisen einer Azure RBAC-Rolle zur systemseitig zugewiesenen verwalteten Identität

Um einer Ressource in Azure eine systemseitig zugewiesene verwaltete Identität zu gewähren, rufen Sie den Befehl az role assignment create auf, um der verwalteten Identität eine Azure RBAC-Rolle zuzuweisen.

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 Network Contributor-Rolle für die benutzerdefinierte Ressourcengruppe zuweisen.

Weisen Sie beispielsweise die Network Contributor-Rolle für die benutzerdefinierte Ressourcengruppe mithilfe des Befehls az role assignment create zu. Stellen Sie für den Parameter --scope die Ressourcen-ID für die Ressourcengruppe für den Cluster bereit.

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

Hinweis

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

Aktivieren einer benutzerseitig zugewiesenen verwalteten Identität

Eine benutzerseitig zugewiesene verwaltete Identität ist eine eigenständige Azure-Ressource. Wenn Sie einen Cluster mit einer benutzerseitig zugewiesenen verwalteten Identität für die Steuerungsebene erstellen, muss die Ressource der benutzerseitig zugewiesenen verwalteten Identität vor der Clustererstellung vorhanden sein. Dieses Feature ermöglicht Szenarien wie das Erstellen des Clusters mit einem benutzerdefinierten VNet oder mit einem ausgehenden Typ von benutzerdefiniertem Routing (UDR).

Erstellen einer benutzerseitig zugewiesenen verwalteten Identität

Wenn Sie noch nicht über eine Ressource der benutzerseitig zugewiesenen verwalteten Identität verfügen, erstellen Sie eine mithilfe des Befehls 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"
}

Abrufen der Prinzipal-ID der benutzerseitig zugewiesenen verwalteten Identität

Um die Prinzipal-ID der benutzerseitig zugewiesenen verwalteten Identität abzurufen, rufen Sie az identity showauf, und fragen Sie die Eigenschaft principalId ab:

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

Abrufen der Ressourcen-ID der benutzerseitig zugewiesenen verwalteten Identität

Um einen Cluster mit einer benutzerseitig zugewiesenen verwalteten Identität zu erstellen, benötigen Sie die Ressourcen-ID für die neue verwaltete Identität. Um die Ressourcen-ID der benutzerseitig zugewiesenen verwalteten Identität abzurufen, rufen Sie az aks showauf, und fragen Sie die Eigenschaft id ab:

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

Zuweisen einer Azure RBAC-Rolle zur benutzerseitig zugewiesenen verwalteten Identität

Bevor Sie den Cluster erstellen, fügen Sie eine Rollenzuweisung für die verwaltete Identität hinzu, indem Sie den Befehl az role assignment create aufrufen.

Im folgenden Beispiel wird der benutzerseitig zugewiesenen verwalteten Identität die Rolle Key Vault-Geheimnisbenutzer zugewiesen, um ihr Berechtigungen für den Zugriff auf Geheimnisse in einem Schlüsseltresor zu gewähren. Die Rollenzuweisung ist auf die Schlüsseltresorressource festgelegt:

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

Hinweis

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

Erstellen eines Clusters mit der benutzerseitig zugewiesenen verwalteten Identität

Rufen Sie den Befehl az aks create auf, um einen AKS-Cluster mit der benutzerseitig zugewiesenen verwalteten Identität zu erstellen. Fügen Sie den Parameter --assign-identity hinzu, und übergeben Sie die Ressourcen-ID für die benutzerseitig zugewiesene verwaltete Identität:

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

Hinweis

Die Regionen „USDOD, Mitte“, „USDOD, Osten“ und „USGov, Iowa“ in der Azure US Government-Cloud unterstützen das Erstellen eines Clusters mit einer benutzerseitig zugewiesenen verwalteten Identität nicht.

Aktualisieren eines vorhandenen Clusters zur Verwendung einer benutzerseitig zugewiesenen verwalteten Identität

Zum Aktualisieren eines vorhandenen Clusters zur Verwendung einer benutzerseitig zugewiesenen verwalteten Identität rufen Sie den Befehl az aks update auf. Fügen Sie den Parameter --assign-identity hinzu, und übergeben Sie die Ressourcen-ID für die benutzerseitig zugewiesene verwaltete Identität:

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

Die Ausgabe bei einer erfolgreichen Clusteraktualisierung zur Verwendung einer benutzerseitig zugewiesenen verwalteten 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>"
      }
    }
  },

Hinweis

Die Migration einer verwalteten Identität für die Steuerungsebene von systemseitig zu benutzerseitig zugewiesen führt nicht zu Ausfallzeiten für Steuerungsebene und Agentpools. Die Komponenten der Steuerungsebene verwenden weiterhin die alte systemseitig zugewiesene Identität bis zu mehreren Stunden bis zur nächsten Tokenaktualisierung.

Ermitteln, welchen Typ von verwalteter Identität ein Cluster verwendet

Um zu ermitteln, welchen Typ von verwalteter Identität Ihr vorhandener AKS-Cluster verwendet, rufen Sie den Befehl az aks show auf, und fragen Sie die Eigenschaft type der Identität ab.

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

Wenn der Cluster eine verwaltete Identität verwendet, ist der Wert der type-Eigenschaft entweder SystemAssigned oder UserAssigned.

Wenn der Cluster einen Dienstprinzipal verwendet, ist der Wert der type-Eigenschaft NULL. Führen Sie gegebenenfalls ein Upgrade Ihres Clusters durch, um eine verwaltete Identität zu verwenden.

Verwenden einer vorab erstellten verwalteten Kubelet-Identität

Eine vorab erstellte Kubelet-Identität ist eine benutzerseitig zugewiesene verwaltete Identität, die vor der Clustererstellung vorhanden ist. Dieses Feature ermöglicht Szenarien wie die Verbindung mit der Azure Container Registry (ACR) während der Clustererstellung.

Hinweis

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

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.

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

Zuweisen einer RBAC-Rolle zu der verwalteten Kubelet-Identität

Weisen Sie die ACRPull-Rolle für die Kubelet-Identität mit dem Befehl az role assignment create zu. Geben Sie die Prinzipal-ID der Kubelet-Identität für die Variable $KUBELET_CLIENT_ID und die ACR-Registrierungs-ID für die Variable $ACR_REGISTRY_ID an.

az role assignment create \
    --assignee $KUBELET_CLIENT_ID \
    --role "acrpull" \
    --scope "$ACR_REGISTRY_ID"

Erstellen eines Clusters zur Verwendung der 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 \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id> \
    --generate-ssh-keys

Eine erfolgreiche AKS-Clustererstellung unter Verwendung einer verwalteten Kubelet-Identität sollte zu einer ähnlichen Ausgabe wie der folgenden führen:

  "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 zur Verwendung der Kubelet-Identität

Um einen vorhandenen Cluster für die Verwendung der verwalteten Kubelet-Identität zu aktualisieren, rufen Sie zunächst die aktuelle verwaltete Identität der Steuerungsebene für Ihren AKS-Cluster ab.

Warnung

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

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

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

    # The cluster is using a managed identity.
{
  "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 --resource-group <RGName> \
    --name <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>"
},

  3. Aktualisieren Sie mithilfe des Befehls az aks update Ihren Cluster mit den vorhandenen Identitäten. Stellen Sie die Ressourcen-ID der benutzerseitig zugewiesenen verwalteten Identität für die Steuerebene für das Argument assign-identity bereit. Stellen Sie die Ressourcen-ID der verwalteten Kubelet-Identität für das Argument assign-kubelet-identity bereit.

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

Hinweis

Wenn Ihr Cluster --attach-acr zum Pullen aus Images aus Azure Container Registry verwendet hat, führen Sie nach dem Aktualisieren Ihres Clusters den Befehl az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR Resource ID> aus, 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 Eigenschaften der Kubelet-Identität

Um die Eigenschaften der Kubelet-Identität abzurufen, rufen Sie az aks show auf, und fragen Sie die Eigenschaft identityProfile.kubeletidentity ab.

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

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

Beachten Sie die folgenden Einschränkungen für die vorab erstellte Kubelet-Identität:

  • Eine vorab erstellte Kubelet-Identität muss eine benutzerseitig zugewiesene verwaltete Identität sein.
  • Die Regionen „China, Osten“ und „China, Norden“ werden in Microsoft Azure operated by 21Vianet nicht unterstützt.

Zusammenfassung der von AKS verwendeten 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 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

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, den Artikel Microsoft Entra-Workload-IDs zu lesen. Die Authentifizierung der Entra-Workload-ID ersetzt das veraltete Feature für die podseitig verwaltete Identität (Vorschau). Die Entra-Workload-ID 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.

Begrenzungen

  • Das Verschieben oder Migrieren von Clustern mit aktivierter verwalteter Identität zu einem anderen Mandanten wird 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 IMDS-Endpunkt gerichtet ist, von NMI abgefangen wird, auch wenn ein bestimmter Pod aad-pod-identity nicht verwendet.

    Die benutzerdefinierte AzurePodIdentityException-Ressourcendefinition (CRD) kann so konfiguriert werden, das sie angibt, dass an den IMDS-Endpunkt gerichtete Anforderungen, die von einem Pod stammen, der in der CRD definierte Bezeichnungen abgleicht, ohne Verarbeitung in NMI über einen Proxy zu senden sind. Schließen Sie die Systempods mit der Bezeichnung kubernetes.azure.com/managedby: aks im Namespace kube-system in aad-pod-identity durch Konfigurieren der AzurePodIdentityException-CRD aus. Weitere Informationen finden Sie unter Verwenden von podseitig verwalteten Microsoft Entra-Identitäten in Azure Kubernetes Service.

    Installieren zur Konfiguration einer Ausnahme die YAML-Datei „mic-exception“.

  • AKS unterstützt die Verwendung einer systemseitig zugewiesenen verwalteten Identität bei Verwendung einer benutzerdefinierten privaten DNS-Zone nicht.

Nächste Schritte

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