Partager via

Utiliser une identité managée dans Azure Kubernetes Service (AKS)

  • Article

Les clusters Azure Kubernetes Service (AKS) requièrent une identité Microsoft Entra pour accéder aux ressources Azure comme les équilibreurs de charge et les disques managés. Les identités managées pour les ressources Azure sont la méthode recommandée pour autoriser l’accès depuis un cluster AKS vers d’autres services Azure.

Vous pouvez utiliser une identité managée pour autoriser l’accès depuis un cluster AKS à n’importe quel service prenant en charge l’autorisation Microsoft Entra, sans avoir à gérer les informations d’identification ou à les inclure dans votre code. Vous attribuez à l’identité managée un rôle de contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour lui octroyer des autorisations à une ressource particulière dans Azure. Par exemple, vous pouvez octroyer des autorisations à une identité managée pour qu’elle accède aux secrets dans un coffre de clés Azure utilisables par le cluster. Pour plus d’informations sur Azure RBAC, consultez Qu’est-ce que le contrôle d’accès en fonction du rôle Azure (Azure RBAC) ?

Cet article explique comment activer les types d’identité managée suivants sur un cluster AKS nouveau ou existant :

  • Identité managée affectée par le système. Une identité managée affectée par le système est associée à une seule ressource Azure, comme un cluster AKS. Elle n’existe que pendant le cycle de vie du cluster.
  • Identité managée affectée par l’utilisateur. Une identité managée affectée par l’utilisateur est une ressource Azure autonome qu’un cluster AKS peut utiliser pour autoriser l’accès à d’autres services Azure. Elle persiste séparément du cluster AKS et peut être utilisé par plusieurs ressources Azure.
  • Identité managée kubelet pré-créée. Une identité managée kubelet pré-créée est une identité affectée par l’utilisateur facultative que kubelet peut utiliser pour accéder à d’autres ressources dans Azure. Si vous ne spécifiez pas d’identité managée affectée par l’utilisateur pour kubelet, AKS crée une identité kubelet affectée par l’utilisateur dans le groupe de ressources de nœud.

Pour en savoir plus sur les identités managées, consultez Identités managées pour les ressources Azure.

Vue d’ensemble

Un cluster AKS utilise une identité managée pour demander des jetons depuis Microsoft Entra. Ces jetons sont utilisés pour autoriser l’accès à d’autres ressources s’exécutant dans Azure. Vous pouvez attribuer un rôle RBAC Azure à une identité managée pour octroyer à votre cluster des autorisations d’accès à des ressources spécifiques. Par exemple, si votre cluster doit accéder aux secrets dans un coffre de clés Azure, vous pouvez attribuer à l’identité managée du cluster un rôle Azure RBAC qui octroie ces autorisations.

Une identité managée peut être soit affectée par le système, soit affectée par l’utilisateur. Ces deux types d’identités managées sont similaires, car vous pouvez utiliser l’une ou l’autre type pour autoriser l’accès aux ressources Azure depuis votre cluster AKS. La principale différence entre elles est qu’une identité managée affectée par le système est associée à une ressource Azure unique, comme un cluster AKS, alors qu’une identité managée affectée par l’utilisateur est elle-même une ressource Azure autonome. Pour plus d’informations sur les différences entre les types d’identités managées, consultez Types d’identité managée dans Identités managées pour les ressources Azure.

Les deux types d’identités managées sont gérés par la plateforme Azure, ce qui vous permet d’autoriser l’accès depuis vos applications, sans avoir à approvisionner ou faire pivoter des secrets. Azure gère les informations d’authentification de l’identité pour vous.

Lorsque vous déployez un cluster AKS, une identité managée affectée par le système est créée par défaut. Vous pouvez également créer le cluster avec une identité managée affectée par l’utilisateur.

Il est également possible de créer un cluster avec un principal de service d’application plutôt qu’une identité managée. Les identités managées sont à préférer aux principaux de service en termes de sécurité et de facilité d’utilisation. Pour plus d’informations sur la création d’un cluster avec un principal de service, consultez Utiliser un principal de service avec Azure Kubernetes Service (AKS).

Vous pouvez mettre à jour un cluster existant pour utiliser une identité managée depuis un principal de service d’application. Vous pouvez également mettre à jour un cluster existant vers un autre type d’identité managée. Si votre cluster utilise déjà une identité managée et que l’identité a été modifiée, par exemple si vous avez modifié le type d’identité du cluster de « affectée par le système » à « affectée par l’utilisateur », alors il y a un retard, pendant que les composants du plan de contrôle basculent vers la nouvelle identité. Les composants du plan de contrôle continue à utiliser l’ancienne identité jusqu’à l’expiration de son jeton. Une fois le jeton actualisé, la nouvelle identité est utilisée. Ce processus peut prendre plusieurs heures.

Les types d’identité affectées par le système et affectées par l’utilisateur diffèrent d’une identité de charge de travail Microsoft Entra, qui est destinée à être utilisée par une application s’exécutant sur un pod.

Avant de commencer

Avant d’exécuter les exemples de cet article, définissez votre abonnement comme abonnement actif actuel en appelant la commande az account set et en transmettant votre ID d’abonnement.

az account set --subscription <subscription-id>

Créez également un groupe de ressources Azure si vous n’en avez pas déjà un, en appelant la commande az group create.

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

Activer une identité managée affectée par le système

Une identité managée affectée par le système est une identité associée à un cluster AKS ou à une autre ressource Azure. L’identité managée affectée par le système est liée au cycle de vie du cluster. Lorsque le cluster est supprimé, l’identité managée affectée par le système est également supprimée.

Le cluster AKS peut utiliser l’identité managée affectée par le système pour autoriser l’accès à d’autres ressources s’exécutant dans Azure. Vous pouvez attribuer un rôle RBAC Azure à l’identité managée affectée par le système pour octroyer au cluster les autorisations d’accès à des ressources spécifiques. Par exemple, si votre cluster doit accéder aux secrets dans un coffre de clés Azure, vous pouvez attribuer à l’identité managée affectée par le système un rôle Azure RBAC qui octroie ces autorisations.

Activer une identité managée affectée par le système sur un nouveau cluster AKS

Pour activer une identité managée affectée par le système sur un nouveau cluster, appelez az aks create. Une identité managée affectée par le système est activée sur le nouveau cluster par défaut.

Créez un cluster AKS avec la commande az aks create.

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

Pour vérifier qu’une identité managée affectée par le système est activée pour le cluster une fois qu’elle a été créée, consultez Déterminer le type d’identité managée qu’un cluster utilise.

Mettre à jour un cluster AKS existant pour qu’il utilise une identité managée affectée par le système

Pour mettre à jour un cluster AKS existant qui utilise un principal de service pour utiliser une identité managée affectée par le système à la place, exécutez la commande az aks update avec le paramètre --enable-managed-identity.

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

Après avoir mis à jour le cluster pour qu’il utilise une identité managée affectée par le système au lieu d’un principal de service, le plan de contrôle et les pods utilisent l’identité managée affectée par le système pour l’autorisation lors de l’accès à d’autres services dans Azure. Kubelet continue d’utiliser un principal de service jusqu’à ce que vous mettez également à niveau votre pool d’agents. Vous pouvez utiliser la commande az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only sur vos nœuds pour effectuer une mise à jour vers une identité managée. Une mise à niveau de pool de nœuds entraîne un temps d’arrêt pour votre cluster AKS, car les nœuds des pools de nœuds sont cordonnés, vidés et ré-imagés.

Remarque

Gardez à l’esprit les informations suivantes lors de la mise à jour de votre cluster :

  • Une mise à jour fonctionne uniquement s’il existe une mise à jour de disque dur virtuel à consommer. Si vous exécutez le disque dur virtuel le plus récent, vous devez attendre que le disque dur virtuel suivant soit disponible pour effectuer la mise à jour.

  • Azure CLI vérifie que l’autorisation de votre module complémentaire est correctement définie après la migration. Si vous n’utilisez pas Azure CLI pour effectuer l’opération de migration, vous devez gérer vous-même l’autorisation de l’identité du module complémentaire. Pour obtenir un exemple d’utilisation d’un modèle Azure Resource Manager (ARM), consultez Attribuer des rôles Azure avec des modèles ARM.

  • Si votre cluster utilisait --attach-acr pour extraire depuis des images d’Azure Container Registry (ACR), vous devez exécuter la commande az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR resource ID> après avoir mis à jour le cluster pour permettre au kubelet nouvellement créé utilisé pour l’identité managée d’obtenir l’autorisation d’extraire depuis ACR. Sinon, vous ne serez pas en mesure de tirer (pull) depuis ACR après la mise à jour.

Ajouter une attribution de rôle pour une identité managée affectée par le système

Vous pouvez attribuer un rôle RBAC Azure à l’identité managée affectée par le système pour octroyer au cluster les autorisations sur une autre ressource Azure. Azure RBAC prend en charge les définitions de rôle intégrées et personnalisées qui spécifient les niveaux d’autorisations. Pour plus d’informations sur l’attribution de rôles RBAC Azure, consultez Étapes pour attribuer un rôle Azure.

Lorsque vous attribuez un rôle RBAC Azure à une identité managée, vous devez définir l’étendue du rôle. En règle générale, il est recommandé de limiter l’étendue d’un rôle aux privilèges minimaux requis par l’identité managée. Pour plus d’informations sur la définition de l’étendue des rôles RBAC Azure, consultez Comprendre les étendues pour RBAC Azure.

Quand vous créez et utilisez votre propre réseau virtuel, vos disques Azure attachés, votre adresse IP statique, votre table de routage ou votre identité kubelet affectée par l’utilisateur où les ressources sont en dehors du groupe de ressources de nœud Worker, l’interface de ligne de commande Azure ajoute automatiquement l’attribution de rôle. Si vous utilisez un modèle ARM ou une autre méthode, utilisez l’ID de principal de l’identité managée du cluster pour effectuer une attribution de rôle.

Si vous n'utilisez pas l’interface de ligne de commande Azure, mais que vous utilisez votre propre réseau virtuel, vos disques Azure attaché, votre adresse IP statique, votre table de routage ou votre identité kubelet affectée par l'utilisateur qui se trouve en dehors du groupe de ressources du nœud Worker, nous vous recommandons d'utiliser Identité managée affectée par l'utilisateur pour le plan de contrôle. Lorsque le plan de contrôle utilise une identité managée affectée par le système, l’identité est créée en même temps que le cluster, de sorte que l’attribution de rôle ne peut pas être effectuée tant que le cluster n’a pas été créé.

Obtenir l’ID de principal de l’identité managée affectée par le système

Pour attribuer un rôle RBAC Azure à l’identité managée affectée par le système d’un cluster, vous avez d’abord besoin de l’ID de principal pour l’identité managée. Obtenez l’ID de principal de l’identité managée affectée par le système d’un cluster en appelant la commande az aks show.

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

Attribuer un rôle RBAC Azure à l’identité managée affectée par le système

Pour octroyer des autorisations à une identité managée affectée par le système sur une ressource dans Azure, appelez la commande az role assignment create pour attribuer un rôle RBAC Azure à l’identité managée.

Pour un réseau virtuel, un disque Azure attaché, une adresse IP statique ou une table de routage en dehors du groupe de ressources du nœud Worker par défaut, vous devez affecter le rôle Network Contributor sur le groupe de ressources personnalisé.

Par exemple, attribuez le rôle Network Contributor sur le groupe de ressources personnalisé en utilisant la commande az role assignment create. Pour le paramètre --scope, indiquez l’ID de ressource du groupe de ressources du cluster.

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

Remarque

La propagation des autorisations octroyées à l’identité managée de votre cluster peut prendre jusqu’à 60 minutes.

Activer une identité managée affectée par l’utilisateur

Une identité managée affectée par l’utilisateur est créée en tant que ressource Azure autonome. Lorsque vous créez un cluster avec une identité managée affectée par l’utilisateur pour le plan de contrôle, la ressource d’identité managée affectée par l’utilisateur doit exister avant la création du cluster. Cette fonctionnalité permet des scénarios tels que la création du cluster avec un réseau virtuel personnalisé ou un type sortant de routage défini par l’utilisateur (UDR).

Créer une identité managée attribuée par l’utilisateur

Si vous n’avez pas encore de ressource d’identité managée affectée par l’utilisateur, créez-en une à l’aide de la commande az identity create.

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

Votre sortie doit ressembler à l’exemple suivant :

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

Obtenir l’ID de principal de l’identité managée affectée par l’utilisateur

Pour obtenir l’ID de principal de l’identité managée affectée par l’utilisateur, appelez az identity show et interrogez sur la propriété principalId :

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

Obtenir l’ID de ressource de l’identité managée affectée par l’utilisateur

Pour créer un cluster avec une identité managée affectée par l’utilisateur, vous aurez besoin de l’ID de ressource pour la nouvelle identité managée. Pour obtenir l’ID de ressource de l’identité managée affectée par l’utilisateur, appelez az aks show et interrogez sur la propriété id :

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

Attribuer un rôle Azure RBAC à l’identité managée affectée par l’utilisateur

Avant de créer le cluster, ajoutez une attribution de rôle pour l’identité managée en appelant la commande az role assignment create.

L’exemple suivant attribue le rôle Utilisateur de secrets Key Vault à l’identité managée affectée par l’utilisateur pour lui octroyer des autorisations d’accès aux secrets dans un coffre de clés. L’attribution de rôle est étendue à la ressource du coffre de clés :

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

Remarque

La propagation des autorisations octroyées à l’identité managée de votre cluster pourrait prendre jusqu’à 60 minutes.

Créer un cluster avec l’identité managée affectée par l’utilisateur

Pour créer un cluster AKS avec l’identité managée affectée par l’utilisateur, appelez la commande az aks create. Incluez le paramètre --assign-identity et transmettez l’ID de ressource pour l’identité managée affectée par l’utilisateur :

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

Remarque

Les régions USDOD Central, USDOD East et USGov Iowa dans le cloud Azure US Government ne prennent pas en charge la création de cluster avec une identité managée affectée par l’utilisateur.

Mettre à jour un cluster existant pour qu’il utilise une identité managée affectée par l’utilisateur

Pour mettre à jour un cluster existant pour qu’il utilise une identité managée affectée par l’utilisateur, appelez la commande az aks update. Incluez le paramètre --assign-identity et transmettez l’ID de ressource pour l’identité managée affectée par l’utilisateur :

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

La sortie d’une mise à jour de cluster réussie pour qu’il utilise une identité managée affectée par l’utilisateur doit ressembler à l’exemple de sortie suivant :

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

Remarque

Migrer une identité managée pour le plan de contrôle, d'une identité affectée par le système à une identité affectée par l'utilisateur, n'entraîne aucun temps d'arrêt, ni pour le plan de contrôle, ni pour les pools d'agents. Les composants du plan de contrôle continuent à utiliser l'ancienne identité affectée par le système pendant plusieurs heures, jusqu'à la prochaine actualisation du jeton.

Déterminer le type d’identité managée qu’un cluster utilise

Pour déterminer le type d’identité managée que votre cluster AKS existant utilise, appelez la commande az aks show et interrogez sur la propriété type de l’identité.

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

Si le cluster utilise une identité managée, la valeur de la propriété type sera soit SystemAssigned soit UserAssigned.

Si le cluster utilise un principal de service, la valeur de la propriété type sera Null. Envisagez de mettre à niveau votre cluster pour qu’il utilise une identité managée.

Utiliser une identité managée kubelet prédéfinie

Une identité kubelet pré-créée est une identité managée affectée par l’utilisateur qui existe avant la création du cluster. Cette fonctionnalité permet des scénarios tels que la connexion à Azure Container Registry (ACR) pendante la création de cluster.

Remarque

AKS crée une identité kubelet affectée à l’utilisateur dans le groupe de ressources Node si vous ne spécifiez pas votre propre identité managée kubelet.

Pour une identité kubelet affectée par l'utilisateur en dehors du groupe de ressources de nœud de travail par défaut, vous devez attribuer le rôle d'opérateur d'identité gérée sur l'identité kubelet pour l'identité gérée du plan de contrôle.

Identité managée kubelet

Si vous n’avez pas encore d’identité managée kubelet, créez-en une avec la commande az identity create.

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

Votre sortie doit ressembler à l’exemple suivant :

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

Attribuer un rôle RBAC à l’identité managée kubelet

Attribuez le rôle ACRPull sur l’identité kubelet avec la commande az role assignment create. Fournissez l’ID principal de l’identité kubelet pour la variable $KUBELET_CLIENT_ID et fournissez l’ID de registre ACR pour la variable $ACR_REGISTRY_ID.

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

Créer un cluster pour qu’il utilise l’identité kubelet

Vous pouvez maintenant créer votre cluster AKS avec vos identités existantes. Assurez-vous de fournir l'ID de ressource de l'identité gérée pour le plan de contrôle en incluant l'argument assign-identity, et l'identité gérée kubelet à l'aide de l'argument assign-kubelet-identity.

Créez un cluster AKS avec vos identités existantes en utilisant la commande 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

Une création de cluster AKS réussie en utilisant une identité managée kubelet doit entraîner une sortie similaire à ce qui suit :

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

Mettre à jour un cluster existant pour qu’il utilise l’identité kubelet

Pour mettre à jour un cluster existant afin qu’il utiliser l’identité managée kubelet, commencez par obtenir l’identité managée du plan de contrôle actuel pour votre cluster AKS.

Avertissement

Mettre à jour l’identité managée kubelet met à niveau les pools de nœuds de votre cluster AKS, ce qui entraîne un temps d’arrêt du cluster car les nœuds des pools de nœuds sont cordonnés, vidés et ré-imagés.

  1. Confirmez que votre cluster AKS utilise l'identité gérée attribuée par l'utilisateur à l'aide de la commande az aks show.

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

    Si votre cluster utilise une identité managée, la sortie indique clientId avec la valeur msi. Un cluster utilisant un principal de service indique un ID d’objet. Par exemple :

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

  2. Après avoir confirmé que votre cluster utilise une identité managée, recherchez l'ID de ressource de l'identité managée à l'aide de la commande az aks show.

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

    Pour une identité managée attribuée par l'utilisateur, votre sortie doit ressembler à l'exemple de sortie suivant :

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

  3. Mettez à jour votre cluster avec vos identités existantes en utilisant la commande az aks update. Indiquez l’ID de ressource de l’identité managée affectée par l’utilisateur pour le plan de contrôle de l’argument assign-identity. Fournissez l’ID de ressource de l’identité managée kubelet pour l’argument 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>

Votre sortie pour la mise à jour d’un cluster en utilisant votre propre identité managée kubelet doit se présenter comme l’exemple de sortie suivante :

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

Remarque

Si votre cluster utilisait --attach-acr pour extraire depuis des images d’Azure Container Registry, exécutez la commande az aks update --resource-group myResourceGroup --name myAKSCluster --attach-acr <ACR Resource ID> après avoir mis à jour le cluster pour permettre au kubelet nouvellement créé utilisé pour l’identité managée d’obtenir l’autorisation d’extraire depuis ACR. Sinon, vous ne serez pas en mesure de tirer (pull) depuis ACR après la mise à niveau.

Obtenir les propriétés de l’identité kubelet

Pour obtenir les propriétés de l’identité kubelet, appelez az aks show et interrogez sur la propriété identityProfile.kubeletidentity.

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

Limitations des identité kubelet pré-créées

Notez les limitations suivantes pour l’identité kubelet pré-créée :

  • Une identité kubelet pré-créée doit être une identité managée affectée par l’utilisateur.
  • Les régions Chine Est et Chine Nord ne sont pas prises en charge dans Microsoft Azure géré par 21Vianet.

Résumé des identités managées utilisées par AKS

AKS utilise plusieurs identités managées pour les services intégrés et les modules complémentaires.

Identité Nom Cas d’utilisation Autorisations par défaut Apportez votre propre identité
Plan de contrôle Nom du cluster AKS Utilisé par les composants du plan de contrôle AKS pour gérer des ressources de cluster, notamment les équilibreurs de charge d’entrée et les adresses IP publiques managées par AKS, la mise à l’échelle automatique des clusters, Azure Disk, le fichier et les pilotes Blob CSI. Rôle Contributeur pour le groupe de ressources du nœud Prise en charge
Kubelet Nom du cluster AKS - agentpool Authentification avec Azure Container Registry (ACR). N/A (pour kubernetes v1.15+) Pris en charge
Composant additionnel AzureNPM Aucune identité requise. N/A Non
Composant additionnel Analyse du réseau AzureCNI Aucune identité requise. N/A Non
Composant additionnel azure-policy (gatekeeper) Aucune identité requise. N/A Non
Composant additionnel azure-policy Aucune identité requise. N/A Non
Composant additionnel Calico Aucune identité requise. N/A Non
Composant additionnel Routage d’applications Gère les certificats Azure DNS et Azure Key Vault Rôle d’utilisateur de Key Vault Secrets pour Key Vault, rôle Collaborateur de zone DNZ pour les zones DNS, rôle Collaborateur de zone DNS privée pour les zones DNS privées Non
Composant additionnel HTTPApplicationRouting Gère les ressources réseau requises. Rôle Lecteur pour le groupe de ressources du nœud, rôle Contributeur pour la zone DNS Non
Composant additionnel Passerelle d'application d’entrée Gère les ressources réseau requises. Rôle Contributeur pour le groupe de ressources du nœud Non
Composant additionnel omsagent Utilisé pour envoyer des métriques AKS à Azure Monitor. Rôle Éditeur des métriques de surveillance Non
Composant additionnel Nœud virtuel (ACIConnector) Gère les ressources réseau requises pour Azure Container Instances (ACI). Rôle Contributeur pour le groupe de ressources du nœud Non
Composant additionnel Analyse des coûts Utilisé pour collecter des données d’allocation des coûts
Identité de la charge de travail ID de la charge de travail Microsoft Entra Permet aux applications d’accéder aux ressources cloud de manière sécurisée avec un ID de charge de travail Microsoft Entra. S/O Non

Important

L'identité managée par pod Microsoft Entra open source (préversion) dans Azure Kubernetes Service est déconseillée depuis le 24/10/2022, et le projet a été archivé en septembre 2023. Si vous souhaitez obtenir plus d’informations, voir l’avis de dépréciation officiel. Le module complémentaire managé AKS commence à être déprécié en septembre 2024.

Nous vous recommandons d’étudier ID de charge de travail Microsoft Entra. L’authentification par l’ID de charge de travail Entra remplace la fonctionnalité d’identité managée par pod (préversion) déconseillée. L’ID de charge de travail Entra est la méthode recommandée pour permettre à une application s’exécutant sur un pod de s’authentifier elle-même auprès d’autres services Azure qui la prennent en charge.

Limites

  • Le déplacement ou la migration d’un cluster avec identité managée vers un autre tenant ne sont pas pris en charge.

  • Si l’identité managée par pod Microsoft Entra (aad-pod-identity) est activée dans le cluster, les pods NMI (Node Managed Identity) modifient les tables d’adresses IP des nœuds pour intercepter les appels vers le point de terminaison Azure Instance Metadata (IMDS). Cette configuration signifie que toute requête adressée au point de terminaison IMDS sont interceptées par NMI, même si un pod particulier n’utilise pas aad-pod-identity.

    La définition de ressource personnalisée AzurePodIdentityException (CRD) peut être configurée pour spécifier que les requêtes adressées au point de terminaison IMDS qui proviennent d’un pod correspondant aux étiquettes définies dans le CRD doivent être envoyées par proxy sans traitement dans NMI. Excluez les pods système avec l’étiquette kubernetes.azure.com/managedby: aks dans l’espace de noms kube-system dans aad-pod-identity en configurant la CRD AzurePodIdentityException. Pour plus d’informations, consultez Utiliser les identités managées par pod Microsoft Entra dans Azure Kubernetes Service.

    Pour configurer une exception, installez le fichier YAML mic-exception.

  • AKS ne prend pas en charge l’utilisation d’une identité managée affectée par le système en cas d’utilisation d’une zone DNS privée personnalisée.

Étapes suivantes