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

Article
03/07/2024

Les clusters Azure Kubernetes Service (AKS) nécessitent une identité pour accéder à des ressources Azure comme des équilibreurs de charge et des disques managés. L’identité peut être une identité managée ou un principal de service.

Cet article fournit des détails sur l’activation des types d’identité managées suivants sur un cluster AKS nouveau ou existant :

Identité managée affectée par le système
Apporter votre propre identité managée affectée par l’utilisateur
Utiliser une identité managée kubelet prédéfinie

Vue d’ensemble

Lorsque vous déployez un cluster AKS, une identité managée affectée par le système est créée automatiquement et elle est gérée par la plateforme Azure, de sorte qu’elle ne vous oblige pas à provisionner ou à faire pivoter des secrets. Pour plus d’informations, consultez Identités managées pour les ressources Azure.

AKS ne crée pas automatiquement un principal de service. Vous devez donc en créer un. Les clusters qui utilisent un principal de service finissent par expirer et le principal de service doit être renouvelé pour éviter d'affecter l'authentification du cluster avec l'identité. La gestion des principaux de service ajoute de la complexité ; il est donc plus facile d’utiliser à la place des identités managées. Les mêmes exigences d’autorisation s’appliquent aux principaux de service et aux identités managées. Les identités managées utilisent l’authentification par certificat. Les informations d’identification de chaque identité managée ont une date d’expiration de 90 jours et elles sont renouvelées après 45 jours.

AKS utilise à la fois les types d’identité managée affectée par le système et affectée par l’utilisateur, et ces identités sont immuables. Ces types d’identité ne doivent pas être confondus avec une identité de charge de travail Microsoft Entra destinée à être utilisée par une application s’exécutant sur un pod.

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’examiner tout d’abord la vue d’ensemble de l’identifiant de charge de travail Microsoft Entra. L’authentification par ID de charge de travail Entra remplace l’identité managée par les pods Microsoft Entra (préversion), tout en étant la méthode recommandée pour permettre à une application s’exécutant sur un pod de s’authentifier auprès d’autres services Azure qui le prennent en charge.

Avant de commencer

Vérifiez qu’Azure CLI version 2.23.0 ou ultérieure est installé. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
Pour utiliser une identité managée kubelet pré-créée, vous devez installer Azure CLI version 2.26.0 ou ultérieure.
Pour mettre à jour l'identité managée sur un cluster existant, vous devez installer Azure CLI version 2.49.0 ou ultérieure.

Limites

Le déplacement de locataires ou la migration de clusters avec des identités managées 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 toutes les requêtes adressées au point de terminaison Metadata sont interceptées par NMI, même si le pod n’utilise pas aad-pod-identity. La CRD AzurePodIdentityException peut être configurée de manière à informer aad-pod-identity de toute requête adressée au point de terminaison Metadata depuis un pod correspondant aux étiquettes définies dans la CRD qui doit être envoyée par proxy sans aucun traitement dans NMI. Les pods système qui disposent de l’étiquette kubernetes.azure.com/managedby: aks dans l’espace de noms kube-system doivent être exclus de aad-pod-identity en configurant la CRD AzurePodIdentityException.
- Pour plus d’informations, consultez Désactiver Microsoft Entra-pod-identity pour un pod ou une application spécifique.
- 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.

Résumé des identités managées

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	tableau de bord	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

Activer les identités managées sur un nouveau cluster AKS

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.

Remarque

Si votre cluster utilise déjà l’identité managée et que l’identité a été modifiée, par exemple, vous modifiez le type d’identité du cluster de « affectée par le système » à « affectée par l’utilisateur », les composants du plan de contrôle n’utilisent pas immédiatement la nouvelle identité. Les composants du plan de contrôle continuent d’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.

Créez un groupe de ressources Azure à l’aide de la commande az group create.
```
az group create --name myResourceGroup --location westus2
```

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

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

Récupérez les informations d’identification pour accéder au cluster avec la commande az aks get-credentials.
```
az aks get-credentials --resource-group myResourceGroup --name myManagedCluster
```

Activer les identités managées sur un cluster AKS existant

Pour mettre à jour votre cluster AKS existant qui utilise un principal de service pour utiliser une identité managée attribuée par le système, exécutez la commande az aks update.

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

Après la mise à jour de votre cluster, le plan de contrôle et les pods utilisent l’identité managée. Kubelet continue à utiliser un principal de service jusqu’à la mise à niveau de 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 du 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 fermés/vidés et réinitialisés.

Notes

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 tirer (pull) à partir d’images d’Azure Container Registry, 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 créé utilisé pour l’identité managée d’obtenir l’autorisation de tirer (pull) 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 l’identité managée

Lorsque vous créez et utilisez votre propre réseau virtuel, attachez des disques Azure, une adresse IP statique, une table de routage ou une identité kubelet attribuée par l'utilisateur lorsque les ressources se trouvent en dehors du groupe de ressources du nœud de travail, Azure CLI ajoute automatiquement l'attribution de rôle. Si vous utilisez un modèle ARM ou une autre méthode, vous devez utiliser l’ID de principal de l’identité managée du cluster pour effectuer une attribution de rôle.

Si vous n'utilisez pas Azure CLI, mais que vous utilisez votre propre réseau virtuel, attachez des disques Azure, une adresse IP statique, une table de routage ou une identité kubelet attribuée par l'utilisateur qui se trouve en dehors du groupe de ressources du nœud de travail, nous vous recommandons d'utiliser user- Identité gérée attribuée pour le plan de contrôle. Pour que le plan de contrôle utilise une identité managée affectée par le système, nous ne pouvons pas obtenir l'ID d'identité avant de créer le cluster, ce qui retarde la prise d'effet de l'attribution de rôle.

Obtenir l'ID principal de l'identité managée

Obtenez l’ID de principal de l’identité existante avec la commande az identity show.

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

Votre sortie doit ressembler à l’exemple suivant :

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

Ajouter une attribution de rôle

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 Contributor sur le groupe de ressources personnalisé.

Attribuez le rôle Contributor sur le groupe de ressources personnalisé avec la commande az role assignment create.

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

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.

Attribuez le rôle Managed Identity Operator sur l’identité kubelet avec la commande az role assignment create.

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

Notes

Le remplissage des autorisations accordées à l’identité managée de votre cluster peut prendre jusqu’à 60 minutes.

Apportez votre propre identité gérée

Créer un cluster à l'aide d'une identité managée attribuée par l'utilisateur

Une identité désignée personnalisée attribuée par l'utilisateur pour le plan de contrôle permet d'accéder à l'identité existante avant la création du cluster. Cette fonctionnalité permet des scénarios tels que l’utilisation d’un réseau virtuel personnalisé ou du paramètre outboundType d’UDR avec une identité managée pré-créée.

Notes

Les régions USDoD - Centre, US DoD - Est et USGov Iowa dans le cloud Azure US Government ne sont pas prises en charge.

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.

Si vous n’avez pas encore d’identité managée, créez-en une avec 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"
}

Notes

Le remplissage des autorisations accordées à l’identité managée de votre cluster peut prendre jusqu’à 60 minutes.

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

Créez le cluster avec l'identité managée attribué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 \
    --enable-managed-identity \
    --assign-identity <identity-resource-id>

Mettre à jour l'identité managée sur un cluster existant

Notes

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

Si vous n’avez pas encore d’identité managée, créez-en une avec 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"
}

Après avoir créé l’identité managée affectée par l’utilisateur personnalisée pour le plan de contrôle, ajoutez l’attribution de rôle pour l’identité managée à l’aide de la commande az role assignment create.

Mettez à jour votre cluster avec vos identités existantes en utilisant la commande az aks update. Assurez-vous de fournir l'ID de ressource de l'identité managée pour le plan de contrôle en incluant l'argument assign-identity.

az aks update \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --enable-managed-identity \
    --assign-identity <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>"
      }
    }
  },

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

Une identité kubelet permet d’accéder à l’identité existante avant la création du cluster. Cette fonctionnalité permet des scénarios tels que la connexion à ACR avec une identité gérée pré-créée.

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

Fonctionne seulement avec un cluster managé affecté par l’utilisateur.
Les régions Chine Est et Chine Nord ne sont pas prises en charge dans Microsoft Azure géré par 21Vianet.

Créer des identités managées affectées par l’utilisateur

Identité managée du plan de contrôle

Si vous n'avez pas d'identité managée pour le plan de contrôle, créez-en une à l'aide de l'extension 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"
}

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

Créer un cluster en utilisant l’identité kubelet affectée par l’utilisateur

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 \
    --enable-managed-identity \
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id>

Un cluster AKS créé 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"
    }
  },

Mettre à jour un cluster existant à l’aide de l’identité kubelet

Avertissement

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

Remarque

Si votre cluster utilisait --attach-acr pour tirer (pull) à partir d’images d’Azure Container Registry, 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 créé utilisé pour l’identité managée d’obtenir l’autorisation de tirer (pull) depuis ACR. Sinon, vous ne serez pas en mesure de tirer (pull) depuis ACR après la mise à niveau.

Obtenir l'identité gérée du plan de contrôle actuel pour votre cluster AKS

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 -g <RGName> -n <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 :
```
{
  "clientId": "msi"
}
```
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 -g <RGName> -n <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>"
},
```

Mettre à jour votre cluster avec l’identité 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"
}

Mettez à jour votre cluster avec vos identités existantes en utilisant la commande az aks update. 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 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"
    }
  },

Étapes suivantes

Utilisez des modèles Azure Resource Manager pour créer un cluster activé pour l’identité managée.
Découvrez comment [utiliser kubelogin][kubelogin-authentication] pour toutes les méthodes d’authentification Microsoft Entra prises en charge dans AKS.

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

Vue d’ensemble

Avant de commencer

Limites

Résumé des identités managées

Activer les identités managées sur un nouveau cluster AKS

Activer les identités managées sur un cluster AKS existant

Ajouter une attribution de rôle pour l’identité managée

Obtenir l'ID principal de l'identité managée

Ajouter une attribution de rôle

Apportez votre propre identité gérée

Créer un cluster à l'aide d'une identité managée attribuée par l'utilisateur

Mettre à jour l'identité managée sur un cluster existant

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

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

Créer des identités managées affectées par l’utilisateur

Identité managée du plan de contrôle

Identité managée kubelet

Créer un cluster en utilisant l’identité kubelet affectée par l’utilisateur

Mettre à jour un cluster existant à l’aide de l’identité kubelet

Obtenir l'identité gérée du plan de contrôle actuel pour votre cluster AKS

Mettre à jour votre cluster avec l’identité kubelet

Étapes suivantes

Ressources supplémentaires