Vue d’ensemble des identités managées dans Azure Kubernetes Service (AKS)

Cet article fournit une vue d’ensemble des identités managées affectées par le système et affectées par l’utilisateur dans AKS, notamment leur fonctionnement, leurs attributions de rôles et les fonctionnalités d’identité managée spécifiques à AKS.

Pour plus d’informations sur les identités managées dans Azure, consultez la documentation sur les identités managées pour les ressources Azure.

Note

Les identités managées couvrent le scénario d’identité cluster-à-Azure dans AKS : comment le cluster AKS agit sur Azure pour gérer les ressources en votre nom. Pour les autres scénarios d’identité (authentification et autorisation du plan de contrôle et identité de charge de travail entre le pod et Azure), consultez les options d’accès et d’identité pour AKS.

Note

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

Flux d’autorisation d’identité managée AKS

Les clusters AKS utilisent des identités managées affectées par le système ou affectées par l’utilisateur pour demander des jetons de Microsoft Entra. Ces jetons permettent d’autoriser l’accès à d’autres ressources s’exécutant dans Azure. Vous attribuez un rôle de contrôle d’accès en fonction du rôle Azure (Azure RBAC) à l’identité managée pour lui accorder des autorisations à une ressource Azure particulière. Par exemple, vous pouvez accorder des autorisations à une identité managée pour accéder aux secrets dans un coffre de clés Azure à utiliser par le cluster.

Comportement de l’identité managée dans AKS

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 ou 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 vous modifiez le type d’identité (par exemple, d'une identité assignée par le système à une identité assignée par l'utilisateur), il y a un délai pendant lequel les composants du plan de contrôle basculent vers la nouvelle identité. Les composants du plan de contrôle continuent d’utiliser l’ancienne identité jusqu’à l’expiration du jeton de l’ancienne identité. Une fois le jeton actualisé, ils basculent vers la nouvelle identité. Ce processus peut prendre plusieurs heures.

Note

Vous pouvez également créer un cluster avec un principal de service d’application plutôt qu’une identité managée. Toutefois, utilisez une identité gérée plutôt qu’un principal de service d’application, pour des raisons de sécurité et de facilité d’utilisation. Si vous disposez d’un cluster existant qui utilise un principal de service d’application, vous pouvez le mettre à jour pour utiliser une identité managée.

Gestion des informations d’identification et des identités AKS

La plateforme Azure gère à la fois les identités managées affectées par le système et les identités affectées par l’utilisateur et leurs informations d’identification. Vous pouvez donc autoriser l’accès à partir de vos applications sans avoir à provisionner ou à faire pivoter des secrets.

Identité gérée attribuée par le système

Le tableau suivant récapitule les principales caractéristiques d’une identité managée affectée par le système dans AKS :

Comment elle est créée Comportement du cycle de vie Partage de ressources Cas d’usage courants dans AKS
Créé dans le cadre d’une ressource Azure, comme un cluster AKS Lié au cycle de vie de la ressource parente, il est donc supprimé lorsque la ressource parente est supprimée Ne peut être associé qu’à une seule ressource • Charges de travail contenues dans une seule ressource Azure
• Charges de travail qui nécessitent des identités indépendantes

Identité gérée assignée par l’utilisateur

Le tableau suivant récapitule les principales caractéristiques d’une identité managée affectée par l’utilisateur dans AKS :

Comment elle est créée Comportement du cycle de vie Partage de ressources Cas d’usage courants dans AKS
Créé en tant que ressource Azure autonome et doit exister avant la création du cluster Indépendamment du cycle de vie d’une ressource spécifique, il nécessite donc une suppression manuelle si elle n’est plus nécessaire Peut être partagé entre plusieurs ressources • Charges de travail qui s’exécutent sur plusieurs ressources et peuvent partager une identité unique
• Charges de travail nécessitant une pré-authentification pour une ressource sécurisée dans le cadre d’un processus d’approvisionnement
• Charges de travail où les ressources sont recyclées fréquemment, mais ont besoin d’autorisations cohérentes

Identité gérée kubelet pré-configurée

Une identité managée kubelet précréée est une identité attribuée par l’utilisateur facultative que kubelet peut utiliser pour accéder à d’autres ressources dans Azure. Cette fonctionnalité permet des scénarios tels que la connexion à Azure Container Registry (ACR) lors de la création du cluster. 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 une identité kubelet assignée par l’utilisateur en dehors du groupe de ressources par défaut des nœuds de travail, attribuez le rôle Opérateur d’identité managée à l’identité du plan de contrôle du cluster, qu’elle soit assignée par le système ou par l’utilisateur, en limitant l’attribution du rôle à l’identité kubelet.

Attributions de rôles pour les identités managées dans AKS

Vous pouvez attribuer un rôle RBAC Azure à une identité managée pour accorder les autorisations de cluster 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 des niveaux d’autorisations. Pour attribuer un rôle, consultez Étapes d’attribution d’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 l’étendue des rôles RBAC Azure, consultez Comprendre l’étendue du RBAC Azure.

Attributions de rôles d’identité managée du plan de contrôle

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

Si vous n'utilisez pas le Azure CLI, mais que vous utilisez votre propre réseau virtuel, attaché Azure disques, adresse IP statique, table de routage ou identité kubelet affectée par l'utilisateur où ces ressources se trouvent en dehors du groupe de ressources de nœud Worker, nous vous recommandons d'utiliser une identité managée affectée par l'utilisateur pour le plan de contrôle et d'effectuer manuellement l'attribution de rôle requise à l'aide de l'ID principal de cette identité.

Lorsque le plan de contrôle utilise une identité managée affectée par le système, vous créez l’identité en même temps que le cluster. Vous ne pouvez donc pas effectuer l’attribution de rôle tant qu’après la création du cluster. Après avoir créé le cluster, obtenez l’ID principal de l’identité et ajoutez l’attribution de rôle requise.

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. Le tableau suivant récapitule les identités managées utilisées par AKS, leurs cas d’utilisation, les autorisations par défaut et si vous pouvez apporter votre propre identité :

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 les ressources de cluster, notamment les équilibreurs de charge d’entrée et les adresses IP publiques gérées par AKS, Cluster Autoscaler, Azure Disk, File, Blob CSI drivers Rôle de contributeur pour le groupe de ressources du nœud Soutenu
Kubelet Name-agentpool du cluster AKS Authentification avec Azure Container Registry (ACR) Aucun ; nécessite un rôle ACR Pull en fonction du mode d’autorisation du registre Soutenu
Composant additionnel AzureNPM Aucune identité requise N/A Non pris en charge
Composant additionnel Surveillance du réseau AzureCNI Aucune identité requise N/A Non pris en charge
Composant additionnel azure-policy (gatekeeper) Aucune identité requise N/A Non pris en charge
Composant additionnel Calico Aucune identité requise N/A Non pris en charge
Composant additionnel routage des applications (NGINX) Gère les certificats Azure DNS et Azure Key Vault rôle Utilisateur de certificats Key Vault pour Key Vault, rôle Contributeur de zone DNS pour les zones DNS Non pris en charge
Composant additionnel ingressapplicationgateway-nom du cluster AKS Gère les ressources réseau requises pour le contrôleur d’entrée Application Gateway (AGIC) Dépend de la topologie de déploiement Non pris en charge
Composant additionnel Aperçus des conteneurs Collecte les journaux de conteneur et les données d’inventaire et les envoie à un espace de travail Log Analytics Utilise l’identité managée du cluster ; aucun rôle de Publisher des métriques de surveillance n’est requis Utilise l’identité du cluster
Composant additionnel Virtual-Node (ACIConnector) Gère les ressources réseau requises pour Azure Container Instances (ACI) Rôle de contributeur pour le groupe de ressources du nœud Non pris en charge
Composant additionnel cost-analysis-identity Collecte les identificateurs de Azure Resource Manager pour l’allocation des coûts Accès en lecture au groupe de ressources du nœud Non pris en charge
Identité de charge de travail Identité Microsoft Entra configurée par l’utilisateur Permet aux applications d’accéder en toute sécurité aux ressources cloud avec l’ID de charge de travail Microsoft Entra Dépend des ressources auxquelles la charge de travail accède Required

Note

L’identité du kubelet requiert le rôle ACR Pull. Pour les registres en mode d’autorisations de registre RBAC, utilisez le rôle AcrPull. Pour les registres en mode RBAC Registry + ABAC Repository Permissions, utilisez le rôle Container Registry Repository Reader. Ajoutez le rôle Container Registry Repository Catalog Lister uniquement si l’identité doit lister les référentiels. Pour plus d’informations, consultez l’identité mappée du nœud AKS.

La ligne de routage d’application décrit l’expérience basée sur NGINX. Microsoft assure la prise en charge des correctifs de sécurité critiques pour les ressources Ingress NGINX du module complémentaire de routage d’application jusqu’en novembre 2026. Migrez vers l’API Application Routing Gateway, ou une autre implémentation prise en charge, d’après novembre 2026. L'intégration DNS et TLS de l'API de passerelle utilise ID de charge de travail Microsoft Entra au lieu de l'identité managée du module complémentaire. Pour l’API de passerelle, créez une identité managée affectée par l’utilisateur, accordez-la aux rôles requis Azure DNS et Azure Key Vault, puis créez des informations d’identification d’identité fédérée pour les comptes de service Kubernetes.

Les autorisations AGIC dépendent de la façon dont vous déployez Application Gateway. Lorsque le module complémentaire crée une passerelle Application Gateway, il attribue généralement automatiquement les autorisations requises. Si vous devez attribuer des autorisations manuellement, accordez le contributeur réseau d’identité de module complémentaire sur le sous-réseau Application Gateway. Pour une passerelle Application Gateway existante dans un groupe de ressources différent de celui du cluster AKS, accordez à l’identité du module complémentaire les rôles « Contributeur réseau » et « Lecteur » sur le groupe de ressources Application Gateway. Pour plus d’informations, consultez Activer AGIC avec une nouvelle passerelle Application Gateway et activer AGIC avec une passerelle Application Gateway existante.

Container Insights utilise par défaut l’authentification d’identité managée et utilise l’identité managée du cluster pour envoyer des données à Azure Monitor. L’authentification héritée, qui nécessitait le rôle d’éditeur des métriques de surveillance, sera abandonnée le 30 septembre 2026. Container Insights collecte les journaux et les données d’inventaire dans un espace de travail Log Analytics ; Azure Monitor service managé pour Prometheus collecte séparément les métriques Prometheus dans un espace de travail Azure Monitor. Pour plus d’informations, consultez l’authentification de Container Insights.

AKS crée le cost-analysis-identity avec un accès en lecture au groupe de ressources des nœuds et l’assigne aux pools de nœuds du cluster lorsque vous activez l’analyse des coûts. Vous ne pouvez pas fournir une identité différente pour le module complémentaire. Pour plus d’informations, consultez Activer l’analyse des coûts AKS.

ID de charge de travail Microsoft Entra est un modèle d’identité d’un pod vers Azure, et non une identité managée du cluster ou d’un module complémentaire. Vous configurez l’identité Microsoft Entra utilisée par chaque charge de travail, annotez le compte de service Kubernetes avec l’ID client de l’identité et créez des informations d’identification d’identité fédérée. Pour plus d’informations, consultez Déployer et configurer ID de charge de travail Microsoft Entra.

Étape suivante

Activez votre type d’identité managée souhaité sur un cluster AKS nouveau ou existant à l’aide des guides suivants :

  • Last updated on