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 activer une identité managée sur un cluster AKS nouveau ou existant, consultez Utiliser une identité managée dans Azure Kubernetes Service (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.

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 gestion continuent d’utiliser l’ancien identifiant jusqu'à ce que son jeton expire. Une fois le jeton actualisé, ils basculent vers la nouvelle identité. Ce processus peut prendre plusieurs heures.

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 :

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 :

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 affectée par l'utilisateur en dehors du groupe de ressources de nœud Worker par défaut, vous devez attribuer le rôle Opérateur d'identité managée sur l'identité kubelet pour l'identité managée du plan de contrôle.

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 Azure CLI, mais que vous 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 qui se trouve 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.

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 qu’après la création du cluster.

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é :

Étape suivante : Activer les identités managées dans AKS

Pour savoir comment activer des identités managées sur un cluster AKS nouveau ou existant, consultez Utiliser une identité managée dans Azure Kubernetes Service (AKS).